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流 计算 是 目前 计算 机 领域 非常 热门 的 技术 ，Storm 平台 的 出 现 大 大 推进 了 该 项 技术 的 发 展 ， 
并 被 很 多 包括 微软 在 内 的 大 公司 采用 。《Storm 源 代码 分 析 》 从 源 代码 角度 深入 浅 出 地 分 析 了 
Storm 的 设计 及 实现 ， 一 方面 可 以 使 读者 更 好 地 了 解 并 用 好 Storm 技术 ， 另 一 方面 可 以 让 读者 学 
习 如 何 设计 大 规模 分 布 式 系统 ， 相 信 读 者 一 定 会 受益 匪 浅 。 


一 一 于 伟 ， 微 软 资深 开发 总 监 


在 当今 互联 网 众多 领域 中 , 大 数据 和 云 计 算 无 疑 是 两 个 最 火 的 主题 , 而 当中 尤其 以 大 数据 的 
实时 流 处 理 为 很 多 开发 者 都 感 兴趣 的 。 作 者 在 书 中 对 Storm 进行 了 详尽 的 介绍 ,按部就班 ， 化 繁 
为 简 ， 让 读者 能 一 步 一 景 地 学 懂 Storm 的 笛 中 细节 ， 实 在 是 Storm 入 门 者 的 必 备 良药 。 

在 我 十 多 载 微 软 职业 生涯 当中 (美国 总 部 和 中 国 ) ， 遇 到 的 技术 大 牛 多 如 繁星 ， 但 李 明 和 了 晓 
鹏 给 我 的 印象 尤为 深刻 。 记 得 当初 我 们 组 建 广告 BI 团队 的 时 候 就 先 立 下 了 采用 开源 技术 这 个 指 
导 思 想 ， 对 传统 的 微软 人 来 说 ， 这 是 开创 先河 之 举 。 李 明和 晓 月 是 最 早 加 入 的 ， 从 第 一 天 开始 ， 
我 就 感觉 到 他 们 对 技术 的 热情 与 执着 。 在 短 短 的 一 个 月 里 , 他 们 不 仅 理解 了 Storm 的 精髓 和 关键 ， 
还 实现 了 一 个 BI pipeline 的 雏形 ， 让 我 们 能 展现 出 实时 流 处 理 大 数据 的 力量 。 在 往 后 的 日 子 里 ， 
每 天 的 工作 量 都 非常 庞大 ,但 更 加 令 我 惊讶 的 是 ,他们 居然 写 了 一 本 关于 Storm 的 书 。 要 知道 学 
懂 一 门 技术 对 于 开发 者 来 说 不 难 ,但 要 著 书 立 说 却 要 经 过 一 定 程 度 的 沉 泻 和 思考 ,并非 旦 夕 之 功 。 
我 拜读 了 他 们 的 初稿 后 ， 发 觉 书 中 对 Storm 的 理解 精辟 透彻 ， 对 Storm 的 运用 和 各 人 处 细节 也 都 阐 
述 入 微 。 尤 其 是 对 Storm 的 人 门 初学 者 来 说 ， 是 一 本 不 可 多 得 的 好 书 。 在 后 续 的 日 子 里 ， 当 我 们 


Storm 的 深刻 了 解 来 解决 问题 。 这 是 一 本 应 该 放 在 桌面 、 随 时 可 以 翻阅 的 参考 书 。 赞 ! 
一 一 章 英 基 ， 前 微软 资深 开发 总 监 ， 现 阿里 巴巴 资深 总 监 


大 数据 处 理 是 当前 计算 机 科技 的 热点 ， 而 流 式 实时 大 数据 处 理 更 是 这 皇冠 上 璀璨 的 明珠 。 实 
时 流 数据 处 理 在 搜索 引擎 、 社 交 网 络 、 电 商 网 站 、 广 告 平 台 等 领域 有 着 相当 广泛 的 应 用 。Storm 
是 极其 高 效 、 灵 活 、 高 扩展 的 流 式 数据 处 理 平台 ， 它 被 Twitter, Taobao, Yahoo! 和 Groupon 等 
公司 采用 。 
本 书 由 微软 公司 互联 网 工程 院 经 验 丰富 的 一 线程 序 员 操 刀 编 写 , 包含 很 多 实战 经 验 和 使 用 心 
得 ， 很 好 地 结合 了 代码 分 析 和 应 用 实例 。 本 书 对 于 进行 流 式 数 据 处 理 的 研究 Storm 的 深入 理解 
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以 及 实际 应 用 都 有 很 好 的 参考 价值 .我 有 幸 与 本 书 作 者 李 明 、 王 晓 月 共同 开发 基于 Storm 的 应 用 ， 
他 们 深厚 的 程序 功力 、 不 懈 的 钻研 精神 令 我 深 深 地 叹服 , 这 在 本 书 中 也 得 到 了 很 好 的 体现 。 我 相 
信 读 者 一 定 会 受益 菲 浅 。 
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本 书 是 国内 为 数 不 多 的 讲述 大 数据 流 计 算 并 进行 源码 分 析 的 一 本 实战 书 。 它 出 自 技术 精湛 并 
且 具 有 丰富 实战 经 验 的 的 微软 工程 师 之 手 ， 我 相信 绝 不 会 让 你 失望 ! 作为 解决 大 数据 5 个 “V” 
之 一 的 “Velocity” 问 题 ，Storm 是 最 流行 的 实时 计算 框架 ， 它 被 认为 是 Hadoop 批 处 理 计算 的 补 
充 , ELE Map/Reduce 更 加 灵活 ， 而 且 性 能 、 可 靠 性 和 可 扩展 性 出 众 ， 所 以 在 Twitter 等 互联 网 公 
司 被 广泛 应 用 到 大 数据 实时 和 准 实时 处 理 的 生产 环境 。 

在 微软 公司 担任 数据 平台 产品 经 理 期 间 ， 我 有 幸 和 李 明 、 王 晓 鹏 等 同事 合作 ， 一 起 将 Storm 
应 用 于 微软 搜索 中 心 的 广告 、 监控、 安全 和 预测 等 应 用 场景 。 在 工作 期 间 , 这 本 书 对 我 帮助 很 大 ， 
即便 对 于 像 我 这 样 在 分 布 式 领域 工作 12 年 的 老手 来 讲 ， 这 本 书 仍然 让 我 受益 良 多 。 无 论 你 是 大 
数据 领域 、 分 布 式 系统 的 从 业 人 员 ， 还 是 开源 系统 的 爱好 者 、 开 发 者 或 互联 网 从 业 人 员 , 我 认为 
这 本 书 都 值得 仔细 研读 。 如 果 你 想 了 解 流 计算 的 设计 原理 ， 想 洞悉 Storm 的 设计 精髓 ,或 揣摩 用 
Clojure， 抑 或 是 探求 如 何 用 Storm 来 解决 大 数据 的 准 实时 需求 场景 ， 这 本 书 都 会 对 你 大 有 神 益 。 
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Storm 是 一 个 分 布 式 的 、 可 靠 的 实时 计算 系统 。 与 Hadoop 的 批 处 理 不 同 ，Storm 采用 流 式 的 
消息 处 理 方法 , 它 使 得 消息 可 以 得 到 快速 的 处 理 ， 可 以 用 于 实时 性 要 求 较 高 的 系统 ,例如 广告 点 
击 的 在 线 统计 等 。Storm 弥补 了 Hadoop 在 实时 处理 方 面 的 缺陷 ， 目 前 被 各 大 互联 网 公司 广泛 使 
用 并 日 益 流 行 。 

本 书 作 为 第 一 本 深入 介绍 Storm 的 图 书 ， 从 源 代码 的 角度 详细 剖析 了 Storm 的 设计 与 实现 。 
本 书 适合 各 类 型 的 计算 机 工作 者 ,初学 者 可 以 通过 本 书 来 学 习 如 何 实 现 一 个 可 靠 的 、 高 容错 性 的 、 
实时 的 分 布 式 处 理 平台 。 而 对 于 Storm 用 户 来 讲 ， 本 书 不 仅 可 以 帮助 他 们 更 深入 地 了 解 这 套 系统 
的 工作 原理 , 还 可 以 帮助 他 们 正确 地 使 用 该 平台 , 也 有 利于 实现 对 Storm 的 二 次 开发 。 鉴于 Storm 
是 基于 Clojure 和 Java 开发 的 ， 所 以 需要 读者 对 这 两 种 语言 有 一 定 的 了 解 。 

本 书 主要 分 析 曾 述 了 Storm 的 底层 架构 ， 例 如 Nimbus, Supervisor, Worker, Executor 以 及 
Task， 并 对 Storm 如 何 实现 可 靠 的 消息 传输 进行 了 系统 讨论 ， 例 如 事务 Topology 以 及 Trident。 

本 书 对 Storm 的 最 新 源 代 码 进行 了 系统 而 详尽 的 分 析 ， 相 信 读 者 在 阅读 过 程 中 一 定 会 获 益 
HE 
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总 体 染 构 与 代码 结构 


Storm 是 由 BackType 开 发 的 一 个 实时 、 分 布 式 的 计算 平台 ， 后 来 Twitter 收购 了 BackType 并 将 
其 源 代码 开放 。 在 GitHub 上 (https://github.com/nathanmarz/storm )， 我 们 可 以 获得 Storm 的 最 新 源 
代码 及 相关 文档 。 


1.4 Storm 的 总 体 结构 


Storm 中 会 涉及 的 术语 包括 Stream、Spout、Bolt、Worker、Executor、Task、Stream Grouping 

和 Topology， 现 简要 介绍 如 下 。 

口 Stream 是 被 处 理 的 数据 。 

口 Spout 是 数据 源 。 

O Bolt 封 装 了 数据 处 理 逻 辑 。 

口 Worker 是 工作 进程 。 一 个 工作 进程 中 可 以 含有 一 个 或 多 个 Executor 线 程 。 

口 Executor 是 运行 Spout 或 Bolt 处 理 逻 辑 的 线程 。 

口 Task 是 Storm 中 的 最 小 处 理 单元 。 一 个 Executor 中 可 以 包含 一 个 或 多 个 Task, 消息 的 分 发 都 

是 从 一 个 Task 到 男 一 个 Task 进 行 的 。 

口 Stream Grouping 定 义 了 消息 分 发 策略 ， 定 义 了 Bolt 节 点 以 何 种 方式 接收 数据 。 消 息 可 以 随 
机 分 配 (Shuffle Grouping， 随 机 分 组 )， 或 者 根据 字段 值 分 配 (Fields Grouping， 字 段 分 
组 )， 或 者 广播 (All Grouping， 全 部 分 组 ), 或 者 总 是 发 给 同一 个 Task (Global Grouping, 
全 局 分 组 )， 也 可 以 不 关心 数据 是 如 何 分 组 的 (None Grouping， 无 分 组 )， 或 者 由 自 定 义 
逻辑 来 决定 , 即 由 消息 发 送 者 决定 应 该 由 消息 接收 者 组 件 的 哪个 Task 来 处 理 该 消息 ( Direct 
Grouping， 直 接 分 组 )。 

口 Topology 是 由 消息 分 组 方式 连接 起 来 的 Spout 和 Bolt 节 点 网 络 , 它 定义 了 运算 处 理 的 拓扑 结 
构 ， 处 理 的 是 不 断 流动 的 消息 。 除 非 杀 掉 Topology， 否 则 它 将 永远 运行 下 去 。 

Storm 的 基本 结构 如 图 1-1 所 示 。 

Storm 和 集群 中 存在 两 种 类 型 的 节点 ; 运行 Nimbus 服 务 的 主 节 点 和 运行 Supervisor 服 务 的 工作 节 

点 。Storm 集 群 由 一 个 主 节 点 和 多 个 工作 节点 组 成 。 主 节点 上 运行 一 个 名 为 “Nimbus” 的 守护 进 

程 ， 用 于 分 配 代码 、 布 置 任务 及 检测 故障 。 每 个 工作 节点 则 运行 一 个 名 为 “Supervisor” 的 守护 
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进程 ， 用 于 监听 工作 、 开 始 并 终止 工作 进程 。 
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ZooKeeper 
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A Supervisor i Supervisor 
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图 1-1 Storm 的 基本 结构 


Nimbus 和 Supervisor 都 能 快速 失败 并 恢复 ,而 且 它们 是 无 状态 的 ,其 元 数据 存储 在 ZooKeeper 
中 , 这 使 得 系统 具有 很 高 的 容错 性 。Nimbus 与 Supervisor 之 间 的 协调 工作 是 通过 ZooKeeper 来 完成 
的 ， 它 是 Apache 下 面 的 开源 项 目 ， 用 于 分 布 式 系统 的 同步 等 ， 详 情 可 参考 http:/zookeeper. 
apacheorg/。 

Worker 由 Supervisor 负 责 启 动 ， 一 个 Worker 中 可 以 有 多 个 Executor 线 程 ， 每 个 Executor 中 又 可 
包含 一 个 或 多 个 Task。Task 为 Storm 中 的 最 小 处 理 单元 ， 它 是 Topology 组 件 诸 多 并 行 度 中 的 一 个 。 
每 个 Executor 都 会 启动 一 个 消息 循环 线程 ， 用 以 接收 、 处 理 和 发 送 消息 。 当 Executor 收 到 属于 其 
下 某 一 Task 的 消息 后 ， 就 会 调用 该 Task 对 应 的 处 理 逻 辑 对 消息 进行 处 理 。 

在 逻辑 上 , Storm 中 消息 的 来 源 节点 被 称 为 Spout, 消息 的 处 理 节 点 被 称 为 Bolt。 在 系统 中 ， 
可 以 存在 多 个 Spout 及 Bolt， 且 每 个 Spout 或 Bolt 都 可 设置 不 同 的 并 行 度 ， 示 例如 图 1-2 所 示 。 
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图 1-2 示例 图 


1.2 Storm 的 元 数据 


Storm 采 用 ZooKeeper 来 存储 Nimbus , Supervisor, 、Worker 以 及 Executor 之 间 共 享 的 元 数据 ， 这 
些 模块 在 重启 之 后 ， 可 以 通过 对 应 的 元 数据 进行 恢复 。 因 此 Storm 的 模块 是 无 状态 的 ， 这 是 保证 
其 可 靠 性 及 可 扩展 性 的 基础 。 了 解 元 数据 以 及 Storm 如 何 使 用 这 些 元 数据 ， 有 助 于 我 们 更 好 地 理 
解 Storm 的 设计 。 


1.2.1 元 数据 介绍 


Storm 在 ZooKeeper 中 存储 数据 的 目录 结构 如 图 1-3 所 示 ， 这 是 一 个 根 路 径 为 /storm 的 树 ， 树 中 
的 每 一 个 节点 代表 ZooKeeper 中 的 一 个 节点 ( znode ), 每 一 个 叶子 节点 是 Storm 真 正 存储 数据 的 地 
方 。 在 图 1-3 中 ， 从 根 节 点 到 叶子 节点 的 全 路 径 代 表 了 该 数据 在 ZooKeeper 中 的 存储 路 径 ， 该 路 径 
可 被 用 来 写 和 人 或 获取 数据 。 
下 面 分 别 介 绍 ZooKeeper 中 每 项 数据 的 具体 含义 。 
口 /storm/workerbeats/<topology-id>/node-port: 它 存储 由 node 和 port 指 定 的 Worker 的 运行 状态 
和 一 些 统计 信息 ， 主 要 包括 storm-id ( 也 即 topology-id )、 当 前 Worker 上 所 有 Executor 的 统 
计 信 息 (如 发 送 的 消息 数目 、 接 收 的 消息 数目 等 )、 当 前 Worker 的 启动 时 间 以 及 最 后 一 次 
更 新 这 些 信息 的 时 间 。 在 一 个 topology-id 下 面 ， 可 能 有 多 个 node-port 节 点 。 它 的 内 容 在 运 
行 过 程 中 会 被 更 新 。 
O /storm/storms/<topology-id>: 它 存储 Topology 本 身 的 信息 ， 包 括 它 的 名 字 、 启 动 时 间 、 
运行 状态 、 要 使 用 的 Worker 数 目 以 及 每 个 组 件 的 并 行 度 设置 。 它 的 内 容 在 运行 过 程 中 是 
不 变 的 。 
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| /workerbeats | | [storms | | fassignments | | [supervisors | | /errors | 


WEN WENN 


/«topolog y-id» /<topology-id> /<supervisor-id> F 
/<topology-id> (StormBase) (Assignment) (Supervis orInfo) /stopology-id> 


/<component-id> 


/node-port 
({:storm-id 
:executor-stats 
:uptime 
:time-secs}) 


/e<sequential-id> 
({:time-secs 
:error]) 


图 1-3 Storm 在 ZooKeeper 中 存储 的 数据 


Q /storm/assignments/<topology-id>: 它 存储 了 Nimbus 为 每 个 Topology 分 配 的 任务 信息 , 包括 
该 Topology 在 Nimbus 机 器 本 地 的 存储 目录 、 被 分 配 到 的 Supervisor 机 器 到 主机 名 的 映射 关 
系 、 每 个 Executor 运 行 在 哪个 Worker 上 以 及 每 个 Executor 的 启动 时 间 。 该 节点 的 数据 在 运 
行 过 程 中 会 被 更 新 。 

口 /storm/supervisors/<supervisor-id>: 它 存储 Supervisor 机 器 本 身 的 运行 统计 信息 ， 主 要 包括 
最 近 一 次 更 新 时 间 、 主 机 名 、supervisor-id、 已 经 使 用 的 端口 列表 、 所 有 的 端口 列表 以 及 
运行 时 间 。 该 节点 的 数据 在 运行 过 程 中 也 会 被 更 新 。 

Q /storm/errors/<topology-id>/<component-id>/e<sequential-id>: 它 存储 运行 过 程 中 每 个 组 件 
上 发 生 的 错误 信息 。<sequential-id> 是 一 个 递增 的 序列 号 ， 每 一 个 组 件 最 多 只 会 保留 最 近 
的 10 条 错误 信息 。 它 的 内 容 在 运行 过 程 中 是 不 变 的 (但 是 有 可 能 被 删除 )。 


1.2.2 ”Storm 怎 么 使 用 这 些 元 数据 


了 解 了 存储 在 ZooKeeper 中 的 数据 ， 我 们 自然 想 知道 Storm 是 如 何 使 用 这 些 元 数据 的 。 例 如 ， 


这 些 数 据 何 时 被 写 人 、 更 新 或 删除 , 这 些 数据 都 是 由 哪 种 类 型 的 节点 (Nimbus、Supervisor、 Worker 
或 者 Executor ) 来 维护 的 。 接 下 来 ,我 们 就 简单 介绍 一 下 这 些 关 系 , 希望 读者 能 对 Storm 的 整体 设 
计 实 现 有 更 深 一 层 的 认识 。 带 上 这 些 知识 ， 能 让 你 的 Storm 源 码 之 路 变 得 更 加 轻松 愉快 。 


首先 来 看 一 下 总 体 交 互 图 ， 如 图 1-4 所 示 。 
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Nimbus 
/ 2. (a) 获取 节点 /storm/workerbeats/<topology-id>/node-port 的 数据 
(b) 获取 节点 /storm/supervisors/<sWipervisor-id> 的 数据 
/ (c) 获取 节点 storm/errors/<topology-id>/<component-id>/e<sequential-id> 的 数据 
1.(a) 创建 节点 M M 7 


4 获取 节点 


(b) 创建 节点 /storm/storms/<topology-id> ; ] 
/storm/assignments/<topology-id> 


并 设置 数据 
(c) 创建 节点 /storm/assignments/<topology-id> 
并 设置 数据 


Supervisor | 所 一 一 9. 读 取 心 跳 信 息 


3. 创建 临时 节点 
/storm/supervisors/<supervisor-id> 
并 设置 数据 启动 /关闭 Worker 
ZooKeeper 
6. 获取 节点 


x /storm/assignments/<topology-id> 
\ E 


Y 


> Worker 


8. 写 入 心跳 信息 


Á 5. 创 建 节点 
| /storm/workerbeats/<topology-id>/node-port 
\ 并 设置 数据 
\ 
M 启动 Executor 
7. 创建 节点 
/storm/errors/<topology-id>/<component-id>/e<sequential-id> 
并 设置 数据 — Executor 


图 1-4 总体 交互 图 


这 个 图 描述 了 Storm 中 每 个 节点 跟 ZooKeeper 内 元 数据 之 间 的 读 写 依赖 关系 ， 详 细 介 绍 如 下 。 
1. Nimbus 


Nimbus 既 需要 在 ZooKeeper 中 创建 元 数据 ,也 需要 从 ZooKeeper 中 获取 元 数据 ,下 面 简 述 图 1-4 


中 箭头 1 和 箭头 2 的 作用 。 
口 箭头 1 表示 由 Nimbus 创 建 的 路 径 ， 包 括 ; 
a. /storm/workerbeats/<topology-id> 
b. /storm/storms/<topology-id> 
c. /storm/assignments/<topology-id> 


其 中 对 于 路 径 a，Nimbus 只 会 创建 路 径 ， 不 会 设置 数据 ( 数据 是 由 Worker 设 置 的 ， 后 面 会 介 
绍 ); 对 于 路 径 b 和 c，Nimbus 在 创建 它们 的 时 候 就 会 设置 数据 。a 和 b 只 有 在 提交 新 Topology 的 时 
候 才 会 创建 ， 且 b 中 的 数据 设置 好 后 就 不 再 变化 ，c 则 在 第 一 次 为 该 Topology 进 行 任务 分 配 的 时 候 


创建 ， 若 任务 分 配 计 划 有 变 ，Nimbus 就 会 更 新 它 的 内 容 。 
O 箭头 2 表示 Nimbus 需 要 获取 数据 的 路 径 ， 包 括 : 
a. /storm/workerbeats/<topology-id>/node-port 
b. /storm/supervisors/<supervisor-id> 
c. /storm/errors/<topology-id>/<component-id>/e<sequential-id> 


Nimbus 需 要 从 路 径 a 读 取 当 前 已 被 分 配 的 Worker 的 运行 状态 。 根 据 该 信息 ，Nimbus 可 以 得 知 
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哪些 Worker 状 态 正常 ， 哪 些 需 要 被 重新 调度 ， 同 时 还 会 获取 到 该 Worker 所 有 Executor 统 计 信 息 ， 
这 些 信息 会 通过 UI 呈现 给 用 户 。 从 路 径 b 可 以 获取 当前 集群 中 所 有 Supervisor 的 状态 , 通过 这 些 信 
息 可 以 得 知 哪些 Supervisor 上 还 有 空闲 的 资源 可 用 ， 哪 些 Supervisor 则 已 经 不 再 活跃 ， 需 要 将 分 配 
到 它 的 任务 分 配 到 其 他 节点 上 。 从 路 径 c 上 可 以 获取 当前 所 有 的 错误 信息 并 通过 UI 呈 现 给 用 户 。 
集群 中 可 以 动态 增 减 机 器 ， 机 器 的 增 减 会 引起 ZooKeeper 中 元 数据 的 变化 ，Nimbus 通 过 不 断 获 取 
D E 故 Storm 具 有 良好 的 可 扩展 性 。 当 Nimbus 死 掉 时 ， 其 他 节点 是 
可 以 继续 工作 的 , 但 是 不 能 提交 新 的 Topology， 也 不 能 重新 进行 任务 分 配 和 负载 调整 ， 因 此 目前 
Nimbus 还 是 存在 单 点 的 | 

2. Supervisor 

同 Nimbus 类 似 ，Superviser 也 要 通过 ZooKeeper 来 创建 和 获取 元 数据 。 除 此 之 外 ，Supervisor 
还 通过 监控 指定 的 本 地 文件 来 检测 由 它 启 动 的 所 有 Worker 的 运行 状态 。 下 面 简 述 图 1-4 中 箭头 3、 
箭头 4 和 箭头 9 的 作用 。 

O 箭头 3 表示 Supervisor 在 ZooKeeper 中 创建 的 路 径 是 /storm/supervisors/<supervisor-id> 。 新 节 
点 加 入 时 ， 会 在 该 路 径 下 创建 一 个 节点 。 值 得 注意 的 是 ， 该 节点 是 一 个 临时 节点 〈 创建 
ZooKeeper 节 点 的 一 种 模式 ), 即 只 要 Supervisor 与 ZooKeeper 的 连接 稳定 存在 , 该 节点 就 一 

HFE; 一 旦 连接 断 开 ,该 节点 则 会 被 自动 删除 。 该 目录 下 的 节点 列表 代表 了 目前 活跃 
的 机 器 。 这 保证 了 Nimbus 能 及 时 得 知 当前 集群 中 机 需 的 状态 ， 这 是 Nimbus 可 以 进行 任务 
分 配 的 基础 ， 也 是 Storm 具 有 容错 性 以 及 可 扩展 性 的 基础 。 

O 箭头 4 表示 Supervisor 需 要 获取 数据 的 路 径 是 /stormyassignments/<topology-id>。 我 们 知道 它 
是 Nimbus 写 人 的 对 Topology 的 任务 分 配 信息 ，Supervisor 从 该 路 径 可 以 获取 到 Nimbus 分 配 

给 它 的 所 有 任务 。Supervisor 在 本 地 保存 上 次 的 分 配 信 息 ， 对 比 这 两 部 分 信息 可 以 得 知 分 

配 信息 息 是 否 有 变化 。 车 发 生变 化 ， 则 需要 关闭 被 移 除 任务 所 对 应 的 Worker， 并 启动 新 的 

Worker 执 行 新 分 配 的 任务 。Nimbus 会 尽量 保持 任务 分 配 的 稳定 性 , 我 们 将 在 第 7 章 中 进行 
详细 分 析 。 

O 箭头 9 表示 Supervisor 会 从 Localstate ( 相关 内 容 会 在 第 4 章 中 介绍 ) 中 获取 由 它 启 动 的 所 有 
Worker 的 心跳 信息 。Supervisor 会 每 隔 一 段 时 间 检 查 一 次 这 些 心跳 信息 ， 如 果 发 现 某 个 
Worker 在 这 段 时 间 内 没有 更 新 心跳 信息 ， 表 明 该 Worker 当 前 的 运行 状态 出 了 问题 。 这 时 
Supervisor 就 会 杀 掉 这 个 Worker， 原 本 分 配给 这 个 Worker 的 任务 也 会 被 Nimbus 重 新 分 Heo 

3. Worker 

Worker 也 需要 利用 ZooKeeper 来 创建 和 获取 元 数据 ， 同 时 它 还 需要 利用 本 地 的 文件 来 记录 自 

己 的 心跳 信息 。 

下 面 简 述 图 4-1 中 箭头 3、 箭头 6 和 箭头 8 的 作用 。 

口 箭头 5 表示 Worker 在 ZooKeeper 中 创建 的 路 径 是 /storm/workerbeats/<topology-id>/node- 
port。 在 Worker 启 动 时 ， 将 创建 一 个 与 其 对 应 的 节点 ， 相 当 于 对 自身 进行 注册 。 需 要 注意 
的 是 , Nimbus 在 Topology 被 提交 时 只 会 创建 路 径 /storm/workerbeats/<topology-id> ， 而 不 会 
设置 数据 ， 数 据 则 留 到 Worker 启 动 之 后 由 Worker 创 建 。 这 样 安排 的 目的 之 一 是 为 了 避免 
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多 个 Worker 同 时 创建 路 径 时 所 导致 的 冲突 。 TEN 
O 箭头 6 表示 Worker 需 要 获取 数据 的 路 径 是 /stormy/assignments/<topology-id> ，Worker 会 从 这 
些 任务 分 配 信息 中 取出 分 配给 它 的 任务 并 执行 。 
O 箭头 8 表示 Worker 在 LocalState 中 保存 心跳 信息 。LocalState 实 际 上 将 这 些 信 息 保存 在 本 
地 文件 中 ,Worker 用 这 些 信息 跟 Supervisor 保 持 心跳 , 每 隔 几 秒 钟 需 要 更 新 一 次 心跳 信息 。 
Worker 与 Supervisor 属 于 不 同 的 进程 ， 因 而 Storm 采 用 本 地 文件 的 方式 来 传递 心跳 。 
4. Executor 
Executor 只 会 利用 ZooKeeper 来 记录 自己 的 运行 错误 信息 ， 下 面 简 述 图 4-1 中 箭头 7 的 作用 。 
箭头 7 表示 Executor 在 ZooKeeper 中 创建 的 路 径 是 /stormy/errors/<topology-id>/<component-id> 
/e<sequential-id>。 每 个 Executor 会 在 运行 过 程 中 记录 发 生 的 错误 。 
5. 小 结 
从 前 面 的 描述 中 可 以 得 知 ，Nimbus 、Supervisor 以 及 Worker 两 两 之 间 都 需要 维持 心跳 信息 ， 
它们 的 心跳 关系 如 下 。 
口 Nimbus 和 Supervisor 之 间 通 过 /storm/supervisors/<supervisor-id> 路 径 对 应 的 数据 进行 心跳 
保持 。Supervisor 创 建 这 个 路 径 时 采用 的 是 临时 节点 模式 ， 所 以 只 要 Supervisor 死 掉 ， 对 应 
路 径 的 数据 就 会 被 删 掉 ，Nimbus 就 会 将 原本 分 配给 该 Supervisor 的 任务 重新 分 配 。 
口 Worker 跟 Nimbus 之 间 通 过 /storm/workerbeats/<topology-id>/mode-port 中 的 数据 进行 心跳 保 
持 。Nimbus 会 每 隔 一 定时 间 获 取 该 路 径 下 的 数据 ， 同 时 Nimbus 还 会 在 它 的 内 存 中 保存 上 
一 次 的 信息 。 如 果 发 现 某 个 Worker 的 心跳 信息 有 一 段 时 间 没 更 新 ， 就 认为 该 Worker 已 经 
死 掉 了 ，Nimbus 会 对 任务 进行 重新 分 配 ， 将 分 配 至 该 Worker 的 任务 分 配给 其 他 Worker。 
口 Worker 跟 Supervisor 之 间 通 过 本 地 文件 ( 基于 LocalState ) 进行 心跳 保持 。 


1.8 Storm 的 代码 结构 


在 本 书 中 ， 我 们 主要 分 析 Storm 0.9.0 的 源 代码 ， 其 下 载 地 址 为 https://github.com/nathanmarz/ 
Stornytree/0.9.0。 
Storm 的 源 代码 主要 基于 Clojure 以 及 Java 来 完成 ， 下 面 简 要 介绍 一 下 主要 的 名 字 空 间 。 


1.3.1 Clojure 代 码 
这 部 分 代码 为 Storm 基 础 架构 的 实现 ， 其 中 Nimbus 、Supervisor 、Worker 、Executor 以 及 Task 
这 些 基础 组 件 的 实现 位 于 srcvclj\backtype.storm 下 ， 如 表 1-1 所 示 。 
表 1-1 Clojure 代 码 


命名 空间 Ho xh 


backtype.storm.daemon.acker AckerBolt 的 实现 


backtype. storm.daemon.builtin-metrics Storm 内 置 统计 信息 
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(ER) 

命名 空间 jo x 
backtype.storm.daemon.common 包含 一 些 工具 方法 以 及 一 些 全 局 定义 
backtype.storm.daemon.drpc Storm DRPC 服 务 器 的 实现 
backtype.storm.daemon.executor Storm Executor 的 实现 
backtype.storm.daemon.nimbus Storm Nimbus 服 务 的 实现 
backtype. storm. daemon. supervisor Storm Supervisor 的 实现 
backtype.storm.daemon.task Storm Task 的 实现 
backtype.storm.daemon.worker Storm Worker 的 实现 
backtype.storm.messaging Storm 的 底层 消息 传输 封装 ， 主 要 对 ZMQ 进 行 封装 
backtype. storm. scheduler Storm 的 Nimbus 使 用 的 任务 调度 算法 实现 
backtype.storm.stats Storm 的 运行 统计 
backtype.storm.ui Storm UI 的 实现 
backtype. storm.disruptor Storm 中 Disruptor Queue 的 使 用 包装 
backtype.storm.cluster Storm 中 对 ZooKeeper 的 使 用 包装 
backtype.storm.zookeeper 基于 CuratorFramework 的 ZooKeeper 使 用 工具 类 
backtype.storm.util Clojure 工 具 方法 集合 ， 该 命名 空间 含有 很 多 的 Clojure 工 具 方 法 
backtype.storm.timer 基于 线程 的 定时 器 实现 
backtype.storm.config Storm 中 配置 项 读 取 以 及 ZooKeeper 中 元 数据 路 径 
backtype. storm.command Topology 的 操作 ， 如 暂停 、 杀 死 等 


1.3.2 ”Java 代码 


这 部 分 代码 含有 Storm 基 础 的 流 处 理 以 及 事务 Topology 的 实现 ,位 于 srcNjvmvbacktype.storm 下 , 
如 表 1-2 所 示 。 


表 1-2 Java 代码 


命名 空间 fa xh 

backtype. storm. coordination 在 Storm 流 处 理 的 基础 上 实现 批 处 理 。DRPC 以 及 事务 Topology 都 
需要 使 用 ，CoordinatedBolt 是 其 中 重要 的 类 实现 

backtype.storm.drpc DRPC 的 高 层 抽象 实现 ， 例 如 DRPCSpout 

backtype.storm.generated 通过 storm.thrift 产 生 的 代码 , 用 于 实现 Nimbus 的 服务 以 及 基础 数 
据 结构 定义 

backtype.storm.grouping J 仿 用户 自 定义 的 分 组 方式 # 

backtype. storm. hooks 含有 系统 的 钩子 方法 接口 , 用 户 可 以 定义 钩子 函数 并 被 Storm 在 适 
当时 机 调用 


backtype. storm.metric 含有 信息 统计 Bolt 的 接口 以 及 SystemBolt 实 现 
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命名 空间 


(5E) 


fa xh 


backtype.storm.nimbus 
backtype.storm.scheduler 


backtype.storm.serialization 


backtype.storm.spout 
backtype.storm.task 
backtype.storm.testing 
backtype.storm.topology 
backtype.storm.transactional 
backtype.storm.tuple 
backtype.storm.utils 


backtype.storm.Config 类 
backtype.storm.Constant 类 


1.9.3 Trident 代码 


Trident 是 Storm 对 实时 消息 处 理 的 更 高 层 抽 象 ， 是 Storm 的 发 展 方向 之 一 ,详情 可 参见 


Topology 有 效 性 检查 的 接口 定义 ， 用 于 Nimbus 
Nimbus 任 务 调度 算法 相关 的 接口 
序列 化 ， 主 要 对 Kryo 的 使 用 进行 封装 ， 提 供 工 具 类 用 于 序列 化 以 及 
反 序列 化 传输 的 消息 
定义 Spout 相 关 接 
定义 Bolt 以 及 相关 接口 ， 定 义 相 关 的 上 下 文 对 象 
用 于 测试 的 一 些 Spout/Bolt 定 义 以 及 工具 方法 
用 于 构建 Storm Topology 的 Java API 

事务 Topology 的 实现 

Storm 的 消息 数据 模型 

Java 工 具 方法 及 数据 结构 

Storm 中 用 到 的 参数 定义 以 及 含义 

系统 内 置 的 组 件 以 及 流 定义 


yu 


https://github.com/nathanmarz/storm/wiki/Trident-tutorial, Tridentf V3 fy T src jvmstorm.trident F , 


具体 如 表 1-3 所 示 。 


命名 空间 


表 1-3 Trident({44 


fa xh 


storm.trident.drpc 
storm.trident.fluent 
storm.trident.graph 
storm.trident.operation 
storm.trident.partition 
storm.trident.planner 
storm.trident.spout 
storm.trident.state 


storm.trident.topology 


storm.trident.tuple 


storm.trident.stream 类 


storm.trident.TridentTopology 类 


用 于 向 DRPC 服 务 器 返回 结果 的 类 实现 
DRPC 的 多 聚集 器 操作 及 分 组 流 
Topology 对 应 的 有 向 图 的 构建 工具 类 
定义 Trident 的 操作 

Trident 的 自 定 义 分 组 算法 

Topology 的 执行 优化 

Trident 中 Spout 封 装 定义 

Trident 中 的 存储 


Trident 的 Topology 构 建 Java API， 以 及 一 些 用 于 同步 的 习 
义 ， 例 如 TridentBolt Executor 


Trident 的 消息 封装 
Trident 中 对 流 的 抽象 ， 是 Trident 的 核心 概念 
用 于 定义 TridentTopology 


yu 


= 
Ri 
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1.3.4 其 他 代码 

除了 以 上 介绍 的 三 部 分 之 外 , Storm 还 定义 了 一 些 基 础 工具 类 以 及 扩展 类 , 主要 包括 以 下 几 项 。 
口 storm.thrift 以 及 genthrift.sh: Storm 基 础 数据 结构 和 服务 的 Thrift 定 义 文件 以 及 产生 脚本 。 
D sre\ui: 定义 了 Storm UI 的 资源 文件 。 
O src\multilang: Storm 的 多 语言 支持 示例 。 
口 src\clj\zilchmq.clj: ZMQ 的 使 用 包装 。 
访问 下 面 的 链接 以 获得 代码 库 结 构 的 相关 信息 : 
https://github.com/nathanmarz/storm/wiki/Structure-of-the-codebase。 
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搭建 Storm 集 群 


在 开始 研究 Storm 之 前 ， 我 们 先 来 搭建 单机 的 和 多 机 的 Storm 运 行 环境 ， 然 后 提交 一 个 示 
例 Topology 到 搭建 好 的 集群 上 使 其 运行 , 最 后 再 分 析 一 下 这 个 示例 Topology 的 组 成 。 通 过 学 习 
这 一 章 并 进行 实践 ， 读 者 不 仅 可 以 对 Storm 有 一 个 初步 的 认识 ， 而 且 能 进一步 了 解 Storm 的 运 
行 原 理 。 


2.1 搭建 单机 Storm 集群 


为 了 更 好 地 理解 Storm 的 运行 原理 ， 我 们 可 以 在 单机 搭建 一 套 Storm 运 行 环境 来 模拟 真实 的 
Storm 集 群 ， 这 有 助 于 我 们 进一步 了 解 Storm 的 运行 机 制 ， 同 时 还 可 以 基于 它 进行 本 地 调试 。 

下 面 我 们 会 一 步 一 步 介 绍 如 何 搭 建 一 个 本 地 的 Storm 运 行 环境 ( 操作 系统 版 本 是 Ubuntu 
12.04 )。 

(1) 下 载 所 需 的 资源 

搭建 Storm 本 地 运行 环境 时 ， 需 要 下 载 的 资源 如 下 所 示 。 
O Storm: http://storm-project.net/downloads.html， 版 本 0.9.0rc2。 
O ZooKeeper: http:/www.apache.org/dyn/closer.cgi/zookeeper/， 版 本 3.4.5。 
口 ZMQ: http:/download.zeromq.org/， 版 本 2.1.7。 
Q jzmq: https://github.com/nathanmarz/jzmq/archive/master.zip。 


我 们 将 下 载 完 的 所 有 文件 保存 在 ~/project/Storm/ 文 件 夹 下 ， 并 分 别 解压 ， 相 关 代 码 如 下 。 


tar -xvf zookeeper-3.4.5.tar.gz 
tar -xvf zookeeper-3.4.5.tar.gz 
unzip jzmq-master.zip 

unzip storm-0.9.0-rc2.zip 


(2) 安装 JDK 
这 里 我 们 使 用 openjdk， 安 装 命 令 是 : 


sudo apt-get install openjdk-7-jdk 


安装 完成 后 ， 需 要 为 其 设置 环境 变量 。 修 改 文件 ~/.profile， 添 加 以 下 内 容 : 
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export JAVA HOME-/usr/lib/jvm/java-7-openjdk-1386 
export CLASSPATH-$JAVA HOME/lib 
export PATH-$JAVA HOME/bin:$PATH 


保存 修改 后 ， 运 行 如 下 命令 使 其 立即 生效 : 


source ~/.profile 


(3) 安装 依赖 的 库 文 件 
Storm 及 其 组 件 需要 依赖 很 多 库 文 件 才能 正常 工作 。 依 次 运行 以 下 命令 ， 安 装 所 有 的 库 : 


sudo apt-get install libtool 
sudo apt-get install autoconf 
sudo apt-get install automake 
sudo apt-get install g++ 

sudo apt-get install uuid-dev 
sudo apt-get install uuid 

sudo apt-get install e2fsprogs 
sudo apt-get install python 


(4) 安装 ZMQ 
进入 解压 后 的 zeromq-2.1.7 文 件 来， 依次 运行 以 下 命令 : 


./configure 

make 

sudo make install 
sudo ldconfig 


(5) 安装 jzmq 
由 于 ZMQ 是 C/C++ 的 库 文件 ，Storm 是 基于 JVM 的 , 没 办 法 直接 使 。jzmq 是 用 JNI 封 装 的 ZMQ 


的 Java 库 ，Storm 需 要 通过 它 来 使 用 ZMQ。 
进入 解压 后 的 jzmq-master 文 件 夹 中 ， 依 次 运行 以 下 命令 : 


./autogen.sh 
./configure 

make 

sudo make install 


如 果 运 行 make 命 令 的 过 程 中 发 生 以 下 错误 


## No rule to make target ^classdist noinst.stamp', needed by ~org/zeromq/ZMQ.class'. Stop. 


则 执行 以 下 操作 。 
首先 ， 执 行 以 下 命令 


touch src/classdist noinst.stamp 


接着 进入 src/org/zeromq 文 件 夹 中 执行 javac *.java 这 条 命令 , 最 后 回 退 到 jzmq-master 文 件 夹 的 
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根 目 录 下 ， 依 次 执行 
make 
sudo make install am 
(6) 启动 ZooKeeper 
进入 解压 后 的 zookeeper-3.4.5 文 件 夹 中 ， 将 文件 ./conf/zoo_sample.cfg 重 命名 为 ./conf/zoo.cfg。 
以 下 命令 启动 ZooKeeper: 


IBF 
bin/zkServer.sh start 


然后 检查 ZooKeeper 是 和 否 成 功 启动 ， 此 时 先 执行 如 下 命 


bin/zkCli.sh -server 127.0.0.1:2181 


此 时 会 出 现 一 个 交互 窗口 ， 在 其 中 运行 1s /。 

(7) 启动 Storm 

进入 解压 后 的 storm-0.9.0-rc2 文 件 夹 的 bn 目录 中 , 依次 执行 以 下 命令 启动 Nimbus、Supervisor 以 及 UI: 
./storm nimbus 


./storm supervisor 
./storm ui 


等 待命 令 都 执行 完成 后 ， 打 开 链 接 http://localhost:8080， 此 时 应 该 能 看 到 Storm UI 界面 。 
(8) 编译 storm-stater jar 包 

接 下 来 ， SUE M 的 集群 上 提交 pes 这 里 我 们 使 用 storm-starter 做 示范 。 
如 果 没 有 安装 过 git 工 具 ， 可 以 运行 下 面 的 命令 安 


sudo apt-get install git 


如 果 没 有 安装 过 leiningen 工 具 ， 则 按照 https://github.com/technomancy/leiningen 的 步骤 安装 。 
FEAT ORE 的 storm-starter 源 代码 保存 在 ~/project/storm-starter 中 。 首 先 ， 进 入 该 目录 中 : 


cd ^/project/storm-starter 
从 GitHub 上 克隆 一 份 storm-starter 的 源 代码 : 
git clone git://github.com/nathanmarz/storm-starter.git 


依次 执行 以 下 命令 创建 项 目 jar 包 : 


lein deps 
lein compile 
lein install 


创建 好 的 jar 包 storm-starter-0.0.1-SNAPSHOT.jar 位 于 target 目 录 下 。 
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(9) 提交 Topology 
进入 storm-0.9.0-rc2 文 件 夹 中 的 bin 目 录 中 ， 运 行 以 下 命令 提交 Topology: 
./storm jar ~/project/storm-stater/target/storm-starter-0.0.1-SNAPSHOT.jar storm.starter.WordCount 
Topology wordcount 
等 待 提交 结束 后 , 刷新 页 面 http://localhost:8080, 我 们 可 以 看 到 提交 的 “wordcount”Topology， 
点 击 Wordcount 可 以 看 到 其 详细 运行 情况 。 
至 此 ,我 们 已 经 成 功 地 在 本 地 搭建 好 Storm 人 和 集群， 并且 成 功 地 运行 了 我 们 的 第 一 个 Topology。 


2.2 ”搭建 多 机 Storm 集群 


我 们 可 以 用 多 人 台 机 器 搭建 一 个 多 机 运行 环境 ， 这 也 是 Storm 的 实际 应 用 场景 ， 下 面 我 们 来 看 
一 下 怎么 搭建 这 样 的 集群 。 
假设 我 们 有 3 台 机 器 MI 、M2 以 及 M3 ， 它 们 的 卫 地 址 分 别 为 10.1.172.1 、10.1.172.2 以 及 
10.1.172.3， 具 体 的 分 配 情况 如 下 : 
口 M1 作为 Nimbus 
口 M2 作为 ZooKeeper 
口 M3 作为 Supervisor 


2.2.1 设置 环境 


Tic. 我们 需要 按照 搭建 单机 集群 的 方式 在 每 台 机 器 上 都 搭建 好 Storm 环 境 ， 也 即 执行 2.1 节 
的 前 5 步 。 

接 下 来 , 修改 M1 和 M3 上 的 storm.yaml 文 件 , 它 的 路 径 是 ~/projecVStormy/storm-0.9.0-rc2/conf/。 
修改 storm.yaml 的 内 容 为 : 


java.library.path: "/usr/local/lib:/usr/lib:/opt/local/lib" 
storm.zookeeper.servers: 
- "10.1.172.2" 
nimbus.host: "10.1.172.1" 
ui.port: 83 
supervisor.slots.ports: 
- 6700 
- 6701 
- 6702 
- 6703 


下 面 解释 一 下 这 些 配置 项 。 

O java.library.path: 该 配置 项 配置 启动 Storm 所 需 lib 包 的 路 径 。 

O storm.zookeeper.servers: 该 配置 项 配置 了 当前 集群 中 所 有 ZooKeeper 机 器 的 耳 地 址 。 我 
们 只 有 一 个 ZooKeeper 服 务 器 ， 所 以 只 配置 了 一 个 IP。 

O nimbus.host: 该 配置 项 指明 了 Nimbus 机 器 的 耻 地 址 。 
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Qui.port: 该 配置 项 配置 了 Storm UI 使 用 的 端口 。 如 果 不 配 置 该 项 ， 默 认 使 用 8080 端 口 ， 

这 里 设置 为 使 用 83 端 口 。 

Q supervisor.slots.ports: 该 配置 项 指明 了 一 台 Supervisor 机 器 上 所 有 可 以 使 用 的 slot 信 息 ， 
也 即 端 口号 。 表 明 该 机 器 上 最 多 可 以 启动 4 个 Worker。 

Storm 还 提供 了 很 多 其 他 配置 项 ， 我 们 会 在 最 后 一 章 中 对 这 些 常见 配置 项 进行 详细 的 介绍 。 


2.2.2 ”启动 Storm 集 群 


首先 ， 在 M2 上 启动 ZooKeeper 服 务 ， 并 验证 它 是 否 成 功 启 动 。 
接 下 来 ， 在 M1 上 进入 storm-0.9.0-rc2 文 件 夹 的 bin 目 录 ， 依 次 执行 以 下 命令 启动 Nimbus 和 UI: 


./storm nimbus 
./storm ui 


最 后 在 M3 上 进入 storm-0.9.0-rc2 文 件 夹 的 bn 目录 中 ， 执 行 以 下 命令 启动 Supervisor: 
./storm supervisor 


等 待 都 启动 完成 后 ， 访 问 http:/10.1.172.1:83 就 能 看 到 启动 起 来 的 集群 。 


2.2.3 提交 Topology 


在 Ml ( 也 即 Nimbus 所 在 的 机 器 ) 上 将 WordCountTopology 提 交 到 集群 中 ， 然 后 刷新 一 下 
http:/10.1.172.1:83 页 面 ， 就 能 看 到 提交 的 Topology 了 。 

至 此 ， 我 们 就 完成 了 部 署 一 个 简单 多 机 Storm 集群 并 提交 Topology 到 集群 运行 的 所 有 步骤 。 
接 下 来 ， 我 们 借助 WordCountTopology 示 例 ， 介 绍 一 下 Topology 的 组 成 。 


2.3 WordCountTopology 介绍 


WordCountTopology 是 一 个 基本 的 Storm Topology， 由 三 个 组 件 构 成 : 
口 RandomSentenceSpout 

Q) SplitSentence 

C) WordCount 

下 面 分 别 介绍 这 几 个 组 件 。 


2.3.1 RandomSentenceSpout 


这 个 类 定义 了 一 个 Spout， 它 继承 自 BaseRichSpout。BaseRichSpout 是 一 个 实现 了 IRichBolt 
接口 的 虚 类 ， 这 个 接口 是 Storm 中 的 一 个 主要 接口 。 它 的 nextTuple 方 法 随机 地 从 一 个 句子 数组 中 
选 出 一 个 句子 发 送出 去 ，declare0utputFields 方 法 声明 了 该 Spout 输 出 的 消息 模式 ， 这 里 输出 只 
有 一 列 ， 字 段 名 是 word: 
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public class RandomSentenceSpout extends BaseRichSpout { 


SpoutOutputCollector collector; 
Random rand; 


@Override 

public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) { 
_collector = collector; 
_rand = new Random(); 


} 


@Override 
public void nextTuple() { 
Utils.sleep(100) ; 
String[] sentences = new String[] { 
"the cow jumped over the moon", 
"an apple a day keeps the doctor away", 
"four score and seven years ago", 
"snow white and the seven dwarfs", 
"i am at two with nature"); 
String sentence = sentences[_rand.nextInt(sentences. length) ]; 
_collector.emit(new Values(sentence)); 


} 


@Override 
public void ack(Object id) { 
} 


@Override 
public void fail(Object id) { 
} 


@Override 
public void declareOutputFields(OutputFieldsDeclarer declarer) { 
declarer.declare(new Fields("word")); 


} 
} 
2.3.2 SplitSentence 
该 类 定义 了 一 个 Bolt， 它 继承 自 BaseBasicBolt。BaseBasicBolt 是 一 个 实现 了 IBasicBolt 接 口 


的 虚 类 。execute 方 法 是 Bolt 真 正 处 理 业 务 逻 辑 的 地 方 ， 它 将 从 Spout 收 到 的 句子 按照 空格 分 割 |， 


I 


然后 把 


式 ， 


每 一 个 单词 作为 一 条 信息 发 送出 去 。declare0utputFields 方 法 声明 该 Bolt 的 输出 消息 格 
这 里 也 只 有 一 列 ， 字 有 段 名 是 word。SplitSentence 类 的 定义 如 下 : 


public static class SplitSentence extends BaseBasicBolt { 


public void execute(Tuple tuple, BasicOutputCollector collector) { 
String sentence = tuple.getString(0); 
for (String word : sentence.split(" ")) 
collector.emit(new Values(word)); 
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@Override 

public void declareOutputFields(OutputFieldsDeclarer declarer) { 
declarer.declare(new Fields("word")); 

) 


2.3.3 WordCount 


类 WordCount 跟 splitsentence 类 似 ， 也 定义 了 一 个 Bolt。 这 个 类 对 收 到 的 所 有 单词 进行 计数 
统计 ，execute 方 法 更 新 收 到 单词 的 缓存 数 ， 并 将 当前 该 单词 及 其 对 应 的 数目 发 送出 去 ; 
declare0utputFields 方 法 声明 该 Bolt 的 输出 消息 格式 ， 这 里 输出 有 两 列 ， 字 上 段 名 分 别 是 word 和 
count; cleanup 方 法 在 该 Topology 被 停 掉 的 时 候 被 调用 (不 保证 一 定 能 够 调用 到 )， 它 将 当前 缓存 
的 所 有 单词 及 数目 信息 打印 到 日 志 中 。 类 WordCount 的 定义 如 下 : 


public static class WordCount extends BaseBasicBolt { 
Map«String, Integer» counts = new HashMap«String, Integer>(); 


@Override 
public void execute(Tuple tuple, BasicOutputCollector collector) { 
String word = tuple.getString(0); 
Integer count = counts.get(word) ; 
if(count==null) count = 0; 
count++; 
counts.put(word, count); 
collector.emit(new Values(word, count)); 


} 


@Override 

public void declareOutputFields(OutputFieldsDeclarer declarer) ( 
declarer.declare(new Fields("word", "count")); 

) 


@Override 
public void cleanup(){ 
for(Map.Entry<String, Integer> entry : counts.entrySet()){ 
logger. info(entry.getKey() + ": " + entry.getValue()); 


} 
2.3.4 WordCountTopology 构 建 


类 WordCountTopology 是 真正 定义 Topology 的 地 方 ， 其 代码 如 下 所 示 : 


1 public class WordCountTopology { 

2 public static void main(String[] args) throws Exception { 

3 TopologyBuilder builder = new TopologyBuilder(); 

4 builder.setSpout("spout", new RandomSentenceSpout(), 5); 
5 builder.setBolt("split", new SplitSentence(), 8) 
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6 .shuffleGrouping("spout"); 
7 builder.setBolt("count", new WordCount(), 12) 
8 .fieldsGrouping("split", new Fields("word")); 


9 

10 Config conf - new Config(); 

11 conf.setDebug(true); 

12 

13 if(args!-null && args.length > 0) ( 

14 conf.setNumWorkers(3); 

15 StormSubmitter.submitTopology("WordCountTopology", conf, builder.createTopology()); 
16 } else { 

17 conf.setMaxTaskParallelism(3); 

18 

19 LocalCluster cluster = new LocalCluster(); 

20 cluster.submitTopology("WordCountTopology", conf, builder.createTopology()); 
21 Thread.sleep(10000) ; 

22 cluster. shutdown(); 

23 } 

24 } 

25 } 


a 第 3 行 创建 一 个 TopologyBuilder 对 象 ， 这 个 类 是 用 来 构建 基本 Topology 的 ， 后 面 我 们 会 详 

细 介 绍 它 。 

a 第 4 行 设置 Topology 的 Spout, 它 的 id 是 spout, 这 里 创建 一 个 RandomSentenceSpout 对 象 作为 

Spout 对 象 ， 并 行 度 设置 为 5。 

O 第 5~6 行 设置 Topology 的 Bolt， 它 的 id 是 split， 这 里 创建 一 个 SplitSentence 对 象 作 为 Bolt 
对 象 ， 并 行 度 设置 为 8 。 它 接收 spout 发 出 的 消息 ， 其 分 组 策略 是 随机 分 组 ( Shuffle 
Grouping )， 即 spout 的 多 个 实例 会 随机 分 发 消息 到 split 的 各 个 实例 上 。 

a 第 7~8 行 设置 Topology 的 另 一 个 Bolt, 它 的 id 是 count, 这 里 创建 一 个 WordCount 对 象 作为 Bolt 
WHA, 并 行 度 设置 为 12, 它 接收 split 发 出 的 消息 , 其 分 组 策略 是 域 分 组 ( Fields Grouping ), 
即 split 的 各 个 实例 会 按照 消息 word 列 所 对 应 的 值 决定 将 消息 发 送 到 count 的 哪个 实例 中 。 
所 有 word 列 值 相同 的 消息 会 被 发 到 同一 个 count 节 点 中 处 理 。 

口 第 10~11 行 设置 该 Topology 所 用 的 配置 信息 ， 这 里 仪 设置 了 调试 模式 为 真 。 这 样 系统 会 打 

印 所 有 发 送 及 接收 的 消息 。 

a 第 13~15 行 是 在 集群 上 提交 该 Topology， 我 们 前 面 介 绍 的 单机 跟 多 机 环境 都 是 用 这 种 方式 

运行 的 。 

口 第 17~22 行 是 直接 运行 该 Topology， 但 它 不 会 提交 到 真实 的 集群 上 。Storm 提 供 了 一 个 

LocalCluster 对 象 来 模拟 集群 运行 环境 , 它 采 用 线程 模拟 进程 的 方式 实现 , 一 般 用 于 调试 

写 好 的 Topology。 
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Storm 编 程 基础 


本 章 将 介绍 一 些 Storm 中 的 基础 概念 ， 以 及 相关 类 和 接口 的 用 法 。 另 外 ,在 网 站 GitHub 的 wiki 
页 面 上 (https://github.com/ nathanmarz/storm/wiki/Concepts )， 还 专门 提供 了 有 关 Storm 核 心 概念 的 
简要 描述 ， 读 者 可 以 将 其 与 本 章 的 讲解 对 照 起 来 进行 学 习 。 


3.1 Fields 定义 


Fields 数 据 结构 用 于 存储 消息 的 字段 名 列表 ， 其 所 需 参 数 是 字段 名 集合 。 对 于 同一 条 消息 ， 
在 构建 Fields 对 象 时 会 为 其 所 有 的 字段 建立 索引 。 它 的 定义 如 下 : 


public class Fields implements Iterable«String», Serializable { 
private List«String» fields; 
private Map«String, Integer» index = new HashMap«String, Integer>(); 


al 

2 

3 

4 

5 public Fields(String... fields) { 
6 this(Arrays.asList(fields)); 
7 

8 


} 
9 public Fields(List<String> fields) { 
10 _fields = new ArrayList<String>(fields.size()); 
11 for (String field : fields) { 
12 if ( fields.contains(field)) 
13 throw new IllegalArgumentException( 
14 String.format("duplicate field '%s'", field) 
15 E 
16 _fields.add(field) ; 
17 
18 index(); 
19 
20 
21 } 


a 第 1 行 表明 Fields 类 实现 了 接口 Iterable<String> 和 Serializable。 接 口 Iterable<Stringy 
定义 了 一 个 迭代 器 接口 ， 用 于 遍历 Fields 中 存储 的 字段 名 列表 ; 接口 Serializable 则 表明 
该 类 是 可 以 被 序列 化 的 。 

a 第 2~3 行 分 别 定 义 了 一 个 保存 所 有 字段 名 的 列表 ,以 及 一 个 保存 了 从 字段 名 到 它 在 字段 名 
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列表 中 位 置 的 映射 表 。 
a 第 5~7 行 的 构造 函数 接收 一 个 可 变 参数 fields ( 也 即 一 个 字段 名 数组 ), 将 fields 转 换 为 列 
表 后 调用 第 9~19 行 定义 的 构造 函数 。 
O 第 9~19 行 定义 的 构造 函数 会 首先 检查 传 信 的 字段 名 列表 中 的 字段 名 是 否 有 重复 ， 并 保存 
该 字段 名 列表 ， 最 后 调用 index 方 法 为 该 字段 名 列表 建立 索引 。 
index 方 法 实际 上 就 是 遍历 字段 名 列表 , 将 每 个 字段 名 和 它 对 应 的 位 置 保存 到 第 3 行 定 义 的 映 
射 表 中 ， 其 代码 如 下 : 


1 private void index() { 
2 for(int i-0; i« fields.size(); i++) ( 
3 _index.put(_fields.get(i), i); 
4 } 
5 } 

此 外 ，Fields 数 据 结构 中 还 定义 了 很 多 常用 方法 ， 比 如 获取 所 有 字段 名 、 获 取 字 段 名 列表 的 
大 小 、 获 取 指 定位 置 的 字段 名 、 获 取 某 个 字段 名 的 索引 位 置 以 及 获取 一 个 所 有 字段 名 的 迭代 器 等 
这 些 方 法 都 相对 简单 易 懂 ， 限 于 篇 幅 ， 此 处 不 再 玲 述 。 


o 


3.2 Tuple 接口 


Tuple 是 Storm 中 的 主要 数据 结构 。 在 Storm 发 送 接收 消息 的 过 程 中 , 每 一 条 消息 实际 上 都 是 一 
个 Tuple 对 象 。 下 面 首先 来 看 一 下 Tuple 接 口 的 定义 : 


public interface Tuple { 
public int size(); 
public int fieldIndex(String field); 
public boolean contains(String field); 


public Object getValue(int i); 

public String getString(int i); 

public Integer getInteger(int i); 

9 public Long getLong(int i); 

10 public Boolean getBoolean(int i); 

11 public Short getShort(int i); 

12 public Byte getByte(int i); 

13 public Double getDouble(int i); 

14 public Float getFloat(int i); 

15 public byte[] getBinary(int i); 

16 

17 public Object getValueByField(String field); 

18 public String getStringByField(String field); 
19 public Integer getIntegerByField(String field); 
20 public Long getLongByField(String field); 

21 public Boolean getBooleanByField(String field); 
22 public Short getShortByField(String field); 

23 public Byte getByteByField(String field); 

24 public Double getDoubleByField(String field); 


1 
2 
3 
4 
5 
6 
7 
8 
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25 public Float getFloatByField(String field); 
26 public byte[] getBinaryByField(String field); 
27 

28 public List«Object» getValues(); 

29 public Fields getFields(); 

30 public List«Object» select(Fields selector); 
31 

32 public GlobalStreamId getSourceGlobalStreamid(); 
33 public String getSourceComponent(); 

34 public int getSourceTask(); 

35 public String getSourceStreamId(); 

36 | public MessageId getMessageId(); 

37 } 


口 第 2 行 的 size 方 法 返回 当前 消息 中 字段 的 数目 。 
口 第 3 行 的 fieldIndex 方 法 可 根据 传人 的 字段 名 获取 该 字段 在 所 有 字段 中 所 处 的 位 置 。 
口 第 4 行 的 contains 方 法 用 来 判断 该 消息 是 否 包 含 指定 的 字段 。 
口 第 6~15 行 的 方法 用 于 获取 由 参数 i 指定 的 字段 位 置 的 值 。 如 果 用 户 知道 该 字段 对 应 的 类 
型 ， 就 可 调用 对 应 类 型 的 获取 方法 获取 字段 的 值 。 若 字段 的 类 型 跟 获 取 方 法 不 匹配 ， 将 
发 生 异 常 。 
口 第 17~26 行 跟 第 6~15 行 类 似 ， 只 不 过 这 里 的 方法 是 根据 字段 名 获取 对 应 的 值 。 定 义 这 些 重 
载 方法 的 目的 都 是 为 了 提高 消息 处 理 的 性 能 。 
口 第 28 行 的 getValues 方 法 用 来 获取 该 消息 存储 的 值 列 表 。 
a 第 29 行 的 getFields 方 法 用 来 获取 存储 了 所 有 字段 名 的 Fields 对 象 。 
口 第 30 行 的 select 方 法 用 来 获取 由 参数 Fields 指 定 的 与 字段 名 对 应 的 值 列 表 。 
a 第 32 行 用 来 获取 与 该 消息 对 应 的 GlobalStreamId， 后 面 我 们 会 介绍 这 个 类 。 
a 第 33 行 用 来 获取 创建 这 个 消息 的 组 件 id。 
a 第 34 行 用 来 获取 创建 这 个 消息 的 TaskId， 第 11 章 将 专门 介绍 Task。 
口 第 35 行 用 来 获取 该 消息 被 发 送 到 的 流 的 序号 。 
O 第 36 行 用 来 获取 该 Tuple 的 消息 序号 , 该 序号 会 被 Storm 用 来 追踪 消息 是 否 处 理 成 功 , 详细 
内 容 请 参考 第 12 章 。 
Storm 提 供 了 Tuple 的 默认 实现 类 TupleImp1。 它 除了 实现 Tuple 接 口 之 外 ， 还 实现 了 Clojure 定 
义 的 几 个 接口 Seqable、Indexed 和 IMeta, 实现 这 些 接口 的 目的 是 为 了 在 Clojure 代 码 中 能 更 好 地 操 
纵 Tuple 对 象 。TupleImp1 的 实现 比较 容易 理解 ， 用 户 可 以 自行 查看 代码 ， 这 里 不 再 蒙 述 。 


3.3 ”常用 声明 接口 


Storm 中 有 多 个 与 组 件 声明 相关 的 类 ， 它们 的 主要 作用 是 让 用 户 更 加 方便 地 定义 组 件 的 输入 
输出 ， 以 及 一 些 与 组 件 相 关 的 配置 ， 其 类 关系 如 图 3-1 所 示 。 
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1 InputDedarer 

© fieldsGrouping(String,Fields) 
® fieldsGrouping(String,String,Fields) T 
® globalGrouping(String) 

® globalGrouping(String,String) 


1 ComponentConfigurationDedarer ® shuffleGrouping (String) T 
® shuffleGrouping (String , String) 


maddConfigurations (Map) T a 
addConfiguration(String,0bject) T| 至 local0rShuffleCrouping(String) 
@maxTaskParallelisn Number | © localOrShffleGrouping(String, String) T 
@debug boolean| "'noneGrouping(String) 
@numTasks Number | “noneGrouping (String, String) 
ipmaxSpoutPending Number | "'allGrouping(String) T 
本 A ®allcrouping (String, String) 
® directGrouping (String) 
9 directGrouping (String , String) T 


æ customGrouping(String,CustomStreamGroup) 
æ customGrouping(String,String,CustomStreamGtouping) 
9 grouping(GlobalStreamId,Grouping) 


€ BaseConfigurationDedarer 
MaddConfiguration(String,Object) T 
™setDebug (boolean) T 
™setMaxTaskParallelism(Number ) T 
T 
T 


1 spoutDedarer 1 BoltDedater 


™setMaxSpoutPending (Number ) 
™setNumTasks (Number) 


1 OutputFieldsDedarer 


dedare(Fields) void 
dedare(boolean,Fields) void 
dedareStream(String,Fields) void 


dedareStream(String,boolea,Fields) 


© OutputFieldsGetter 


dedare(Fields) void 
dedare(boolean,Fielde) void 
dedareStream(String,Fields) void 


dedareStream(String,boolean,Fields)id 
® fieldsDedaration:p«String,StreamInfo» 
Powered byyFiles 


图 3-1 ”常用 声明 接口 


3.3.1 配置 声明 接口 


ComponentConfigurationDeclarer 接 口 定义 了 一 些 和 组 件 相 关 的 配置 项 ,该 接口 中 定义 的 方法 
返回 值 为 通用 类 型 7， 且 T 实 现 了 ComponentConfigurationDeclarer。 由 于 该 接口 中 的 这 些 方法 返 
回 的 是 相同 的 对 象 ， 因 此 在 用 法 上 可 以 实现 方法 的 级 联 。 该 接口 的 定义 如 下 。 


public interface ComponentConfigurationDeclarer«T extends ComponentConfigurationDeclarer» ( 
T addConfigurations(Map conf); 
T addConfiguration(String config, Object value); 
T setDebug(boolean debug); 
T setMaxTaskParallelism(Number val); 
T setMaxSpoutPending(Number val); 
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T setNumTasks(Number val); 


} 


Storm 默 认 提 供 了 一 个 抽象 类 BaseConfigurationDeclarer ， 它 实现 了 以 上 接口 中 除 addConfi 
gurations(Map conf) 以 外 的 大 部 分 方法 : 


public abstract class BaseConfigurationDeclarer<T extends ComponentConfigurationDeclarer> implements 


ComponentConfigurationDeclarer<T> { 
@Override 


public T addConfiguration(String config, Object value) { 
Map configMap = new HashMap(); 
configMap.put(config, value); 
return addConfigurations(configMap) ; 


} 


@Override 
public T setDebug(boolean debug) { 

return addConfiguration(Config. TOPOLOGY DEBUG, debug); 
} 


@Override 
public T setMaxTaskParallelism(Number val) { 

if(val!=null) val = val.intValue(); 

return addConfiguration(Config. TOPOLOGY MAX TASK PARALLELISM, val); 
) 


@Override 
public T setMaxSpoutPending(Number val) { 

if(val!=null) val = val.intValue(); 

return addConfiguration(Config. TOPOLOGY MAX SPOUT PENDING, val); 
) 


@Override 
public T setNumTasks(Number val) { 
if(val!=null) val = val.intValue(); 
return addConfiguration(Config. TOPOLOGY TASKS, val); 


3.3.2 输入 声明 接口 


接口 InputDeclarer 采 用 了 类 似 ComponentConfigurationDeclarer 的 定义 方式 ， 即 可 以 级 联 使 
用 ,用 于 声明 一 个 组 件 的 输入 ,定义 如 下 : 
public interface InputDeclarer«T extends InputDeclarer> { 


public T fieldsGrouping(String componentId, Fields fields); 
public T fieldsGrouping(String componentId, String streamId, Fields fields); 


public T globalGrouping(String componentId); 
public T globalGrouping(String componentId, String streamId); 
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public 
public 


public 
public 


public 
public 


public 
public 


public 
public 


public 
public 


public 


} 


shuffleGrouping(String componentId); 
shuffleGrouping(String componentId, String streamId); 


localOrShuffleGrouping(String componentId); 
localOrShuffleGrouping(String componentId, String streamId); 


noneGrouping(String componentId); 
noneGrouping(String componentId, String streamId); 


allGrouping(String componentId); 
allGrouping(String componentId, String streamId); 


directGrouping(String componentId); 
directGrouping(String componentId, String streamId); 


customGrouping(String componentId, CustomStreamGrouping grouping); 
customGrouping(String componentId, String streamId, CustomStreamGrouping grouping); 


T grouping(GlobalStreamId id, Grouping grouping); 


其 中 定义 了 各 种 分 组 方式 ,每 个 方法 的 返回 值 均 为 类 型 T, 即 实际 运行 中 实现 了 InputDeclarer 
的 类 型 。 如 果 有 多 个 输入 ， 这 样 定义 之 后 就 可 以 用 级 联 的 方式 声明 多 个 输入 的 分 组 方式 。 

如 果 不 指 定 流 序 号 ， 则 表示 默认 在 ID 为 default 的 流 上 进行 分 组 。 

该 接口 在 创建 Topology 的 时 候 会 用 到 。 


3.8.8 输出 字段 声明 接口 


接口 0utputFieldsDeclarer 定 义 了 Topology 中 每 个 组 件 的 输出 字段 声明 。 这 个 接口 非常 重要 ， 
每 个 Topology 中 的 组 件 都 需要 用 它 来 指定 输出 到 哪些 流 、 声 明 输 出 的 字段 列表 以 及 指明 输出 流 是 
否 是 直接 流 (Direct Stream )。 它 的 定义 如 下 : 


public interface OutputFieldsDeclarer { 


1 

2 /** 

3 * Uses 
4 */ 

5 public 
6 public 
7 

8 public 
9 public 
10} 


default stream id. 


void declare(Fields fields); 
void declare(boolean direct, Fields fields); 


void declareStream(String streamId, Fields fields); 
void declareStream(String streamId, boolean direct, Fields fields); 


它 使 用 了 我 们 前 面 介 绍 过 的 Fields 对 象 来 声明 输出 字段 列表 。 第 5~6 行 的 方法 没有 指明 输出 
流 号 ， 默 认 使 用 的 是 default。 第 5 行 和 第 8 行 的 方法 没有 指明 是 否 为 直接 流 ， 默 认 是 不 使 用 直接 
流 的 方式 输出 。 本 书 的 后 续 章 节 会 介绍 直接 流 方式 输出 的 相关 概念 ,以 及 何 时 使 用 直接 流 方式 的 


输出 。 
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3.3.4 组 件 声明 接口 


Storm 中 的 组 件 包 括 Spout 和 Bolt， 所 以 组 件 声明 接口 也 有 两 种 : Spout Dedarer 和 BoltDeclarer。 
接口 SpoutDeclarer 仅 仅 是 简单 地 继承 了 接口 ComponentConfigurationDeclarer ， 用 于 声明 一 
个 组 件 以 及 设 定 配置 项 ， 其 定义 如 下 : 


public interface SpoutDeclarer extends ComponentConfigurationDeclarer<SpoutDeclarer> { 


} 
接口 BoltDeclarer 同 时 继承 了 接口 ComponentConfigurationDeclarer 以 及 接口 InputDeclarer: 


public interface BoltDeclarer extends InputDeclarer<BoltDeclarer>, ComponentConfigurationDeclarer 
BoltDeclarer> { 


} 


从 用 户 的 角度 来 看 ，Spout 表 示 了 消息 的 源头 ， 即 Spout 是 没有 输入 的 ， 而 Bolt 是 中 间 的 处 理 
节点 ， 它 需要 定义 它 的 输入 ， 即 需要 实现 InputDeclarer 接 口 。 


3.4 Spout 输出 收集 器 


Storm 只 定义 了 一 个 Spout 和 输出 收集 需 的 接口 ITSpoutOutputCollector ， 并 提供 了 它 的 一 个 默认 
实现 Spout0utputCollector。 在 Executor 中 ， 我 们 提供 了 ISpout0utputCollector 接 口 的 真正 实现 。 
下 面 我 们 分 别 予 以 介绍 。 


3.4.1 ISpoutOutputCollector#SpoutOutputCollector 


首先 看 一 下 ISpoutOutputCollector 接 口 的 定义 : 


public interface ISpoutOutputCollector { 
[** 
Returns the task ids that received the tuples. 
X 
List<Integer> emit(String streamId, List«Object» tuple, Object messageId); 
void emitDirect(int taskId, String streamId, List«Object» tuple, Object messageId); 
void reportError(Throwable error); 


j 
口 emit 方 法 用 来 向 外 发 送 数据 , 它 的 返回 值 是 该 消息 所 有 发 送 目标 的 TaskId 集 合 ， 其 输入 参 
数 的 含义 如 下 。 
m streamId: 消息 将 被 输出 到 的 流 。 
m tuple: 要 输出 的 消息 ， 为 一 个 Object 列表 。 
m messageld: 输出 消息 的 标记 信息 。 如 果 messageId 被 设置 为 nu11，Storm 将 不 会 追踪 该 消 
息 ， 否 则 它 会 被 用 来 追踪 所 发 出 消息 的 处 理 情况 ， 具 体 情况 可 参考 第 12 章 。 
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O emitDirect 方 法 的 输入 列表 与 emit 方 法 相似 ， 主 要 区 别 在 于 使 用 emitDirect 时 ， 只 有 由 人 参 
数 taskId 所 指定 的 Task 才 可 以 接收 这 条 消息 。 这 个 方法 要 求 与 参数 streamId 相 对 应 的 流 必 
须 被 定义 为 直接 流 ， 同 时 接收 端的 Task 也 必须 以 直接 分 组 (Direct Grouping ) 的 方式 来 接 
收 消息 ， 否 则 会 有 异常 抛 出 。 男 外 ， 如 果 没 有 下 游 节 点 接收 该 消息 ， 那 么 该 消息 其 实 也 
就 没有 被 真正 发 送 。 
口 reportError 方 法 用 来 处 理 异常 。 
EFE, 我 们 看 一 下 Storm 提 供 的 该 接口 的 默认 实现 类 Spout0utputCollector。 这 个 类 实际 上 
是 一 个 代理 类 , 它 本 身 也 封装 了 一 个 ISpout0utputCollector 对 象 , 所 有 的 操作 实际 上 都 是 通过 该 
对 象 来 实现 的 。 除 此 之 外 ， 它 还 提供 了 一 些 重 载 方法 以 方便 用 户 使 用 。 该 类 的 定义 如 下 所 示 : 


1 public class SpoutOutputCollector implements ISpoutOutputCollector { 

2 ISpoutOutputCollector delegate; 

3 

4 public SpoutOutputCollector(ISpoutOutputCollector delegate) { 

5 . delegate = delegate; 

6 ) 

7 

8 public List«Integer» emit(String streamId, List«Object» tuple, Object messageId) { 
9 return delegate.emit(streamId, tuple, messageld); 

10 } 

11 

12 public List«Integer» emit(List<Object> tuple, Object messageId) { 

13 return emit(Utils.DEFAULT STREAM ID, tuple, messageId); 

14 } 

15 

16 public List«Integer» emit(List<Object> tuple) { 

17 return emit(tuple, null); 

18 } 

19 

20 public List<Integer> emit(String streamId, List<Object> tuple) { 

21 return emit(streamId, tuple, null); 

22 } 

23 

24 . public void emitDirect(int taskId, String streamId, List<Object> tuple, Object messageId) { 
25  delegate.emitDirect(taskId, streamId, tuple, messageId); 

26 } 

27 

28 public void emitDirect(int taskId, List<Object> tuple, Object messageId) { 
29 emitDirect(taskId, Utils.DEFAULT STREAM ID, tuple, messageId); 

30 } 

31 

32 public void emitDirect(int taskId, String streamId, List<Object> tuple) { 
33 emitDirect(taskId, streamId, tuple, null); 

34 } 

35 

36 public void emitDirect(int taskId, List«Object» tuple) { 

37 emitDirect(taskId, tuple, null); 

38 j 


3.4 Spout 输出 收集 器 27 


40 @Override 

41 public void reportError(Throwable error) { 

42 . delegate.reportError(error); 

43] 

44) 

a 第 2 行 定 义 了 它 所 代理 的 ISpoutOutputCollector 对 象 。 

O 第 4~6 行 定义 构造 函数 ， 它 接收 一 个 ISpout0utputCollector 对 象 ， 并 将 其 保存 在 第 2 行 定 
义 的 变量 中 。 

O 第 8~22 行 实现 了 接口 中 的 emit 函 数 ， 并 且 提 供 了 它 的 几 个 重 载 方法 。 比 如 ， 如 果 不 指定 
streamId， 默 认 使 用 default; 如 果 不 指定 messageId， 则 默认 使 用 空 (null). 

O 第 24~38 行 实现 了 接口 中 的 emitDirect 函 数 ， 同 时 也 提供 了 几 个 重 载 方法 ， 这 跟 emit 函 数 
是 一 致 的 。 

口 第 41~43 行 定义 了 reportError 的 实现 。 


3.4.2 ”Executor 中 ISpoutOutputCollector 的 实现 


Executor 在 调用 Spout 的 prepare 方 法 时 也 提供 了 一 种 ISpout0utputCollector 接 口 的 实现 。 以 
下 代码 在 文件 executor.clj 中 : 


1 (SpoutOutputCollector. 

2 (reify ISpoutOutputCollector 

3 (^List emit [this ^String stream-id “List tuple “Object message-id] 
4 (send-spout-msg stream-id tuple message-id nil) 

5 

6 (^void emitDirect [this ^int out-task-id ^String stream-id 
7 “List tuple “Object message-id] 

8 (send-spout-msg stream-id tuple message-id out-task-id) 
9 

10 (xeportError [this error] 

11 (report-error error) 

12 )) 


口 第 2~12 行 定义 了 ISpoutOutputCollector 的 实现 。 第 1 行 初始 化 了 一 个 SpoutOutput- 
Collector 对 象 ， 用 户 代码 通过 这 个 对 象 向 外 发 送 数 据 ，Storm 中 所 有 Spout 的 输出 收集 融 
归根 到 底 都 是 使 用 该 对 象 向 外 发 送 数 据 的 。reify 是 Clojure 的 关键 字 ， 它 用 于 实现 一 个 接 
口 ， 并 初始 化 一 个 对 象 。 

O 第 3~5 行 定义 了 emit 方 法 ， 它 通过 调用 函数 send-spout-msg 来 发 送 数 据 ， 该 函数 会 在 第 10 

章 中 详细 介绍 。 

O 第 6~9 行 定义 了 emitDirect 方 法 ， 它 同 emit 方 法 类 似 ， 也 是 通过 调用 函数 send-spout-msg 

来 发 送 数据 的 。 

O 第 10~12 行 定义 了 reportError 方 法 ， 它 是 通过 调用 report-error 方 法 实现 的 ， 该 方法 也 将 
在 第 10 章 中 介绍 。 
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3.5 Bolt 输出 收集 器 


用 户 在 实现 Bolt 时 要 明确 : Bolt 处 理 好 的 消息 都 是 通过 输出 收集 器 发 送出 去 的 ， 不 同类 型 的 
Bolt 所 使 用 的 输出 收集 器 也 是 不 同 的 ， 下 面 简 要 介绍 一 下 。 
口 IRichBolt: 它 使 用 OutputCollector 输 出 收集 器 ， 该 收集 顺 实 现 的 是 IOutputCollector 接 
口 ， 实 际 上 是 一 个 代理 类 。 
口 IBasicBolt : 它 使 用 BasicOutputCollector 输 出 收集 器 ,该 收集 器 实际 上 是 0utputCollector 
的 封装 类 ， 实 现 的 是 IBasicOutputCoLllector 接 口 。 
口 IBatchBolt: 它 使 用 BatchoutputCollector 输 出 收集 器 ， 该 收集 器 是 一 个 虚 基 类 ，Storm 提 
HET E AY BRAGA SE HE BatchOutputCollectorImpl ， 这 个 类 实际 上 也 是 通过 封装 
OutputCollector 类 来 实现 消息 发 送 的 。 
下 面 我 们 分 别 对 这 几 种 输出 收集 器 进行 介绍 。 


3.5.1 IOutputCollector 和 OutputCollector 


接口 TErrorReporter 定 义 了 reportError 方 法 , 其 输入 为 一 个 Throwable 对 象 , 用 户 可 以 在 该 方 
法 中 处 理 异 常 : 


public interface IErrorReporter { 
void reportError(Throwable error); 
} 


接口 IOutputCollector 扩 展 了 接口 IErrorReporter， 并 且 定 义 了 一 些 基本 方法 : 
public interface IOutputCollector extends IErrorReporter { 
/** 
* Returns the task ids that received the tuples. 
*/ 
List<Integer> emit(String streamId, Collection«Tuple» anchors, List«Object» tuple); 
void emitDirect(int taskId, String streamId, Collection«Tuple» anchors, List«Object» tuple); 
void ack(Tuple input); 
void fail(Tuple input); 
} 
O emit 方 法 用 来 向 外 发 送 数据 ,， 它 的 返回 值 是 该 消息 所 有 发 送 目标 的 TaskId 集 合 ， 其 输入 参 
数 的 含义 如 下 所 示 。 
m streamId: 消息 将 被 输出 到 的 流 。 
m anchors: 输出 消息 的 标记 ， 通 常 代表 该 条 消息 是 由 哪些 消息 产生 的 ， 主 要 用 于 消息 的 
Ack 系 统 。 
m tuple: 要 输出 的 消息 ， 为 一 个 Object 列 表 。 
O emitDirect 方 法 的 输入 列表 与 emit 方 法 相似 ， 主 要 区 别 在 于 ，emitDirect 发 送 的 消息 只 有 
指定 的 Task 才 可 以 接收 。 这 个 方法 要 求 streamId 对 应 的 流 必须 被 定义 为 直接 流 ， 同 时 接收 
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端的 Task 必 须 通 过 直接 分 组 的 方式 来 接收 消息 , 否则 会 抛 出 异常 。 如 果 没 有 下 游 节 点 接收 
该 消息 ， 那 么 此 类 消息 其 实 也 就 没有 被 真正 发 送 。 
口 fail 和 ack 方 法 用 来 表示 消息 是 否 被 成 功 处 理 。 
Storm 提 供 了 IOutputCollector 接 口 的 默认 实现 类 0utputCollector， 它 实际 上 也 是 一 个 代理 。 
它 包含 一 个 真正 工作 的 I0utputCollector 实 例 ， 这 个 对 象 是 在 Clojure 代 码 中 定义 的 。0Output 
Collector 主 要 用 于 从 IRichBolt 向 外 发 送 数 据 。 在 0utputCollector 的 实现 中 ， 所 有 操作 都 由 代理 
对 象 完成 。 而 且 ，0utputCollector 还 提供 了 很 多 重 载 的 方法 以 方便 用 户 使 用 ， 其 定义 如 下 : 


/** 
* This output collector exposes the API for emitting tuples from an IRichBolt. 
* This is the core API for emitting tuples. For a simpler API, and a more restricted 
* form of stream processing, see IBasicBolt and BasicOutputCollector. 
*/ 
public class OutputCollector implements IOutputCollector ( 
private IOutputCollector delegate; 


O CON AUBWN PR 


10 public OutputCollector(IOutputCollector delegate) { 
11 delegate = delegate; 
12 } 


* Emits a new tuple to a specific stream with a single anchor. The emitted values must be 
16 * immutable. 
* 


[zy 
oo 
* 


Gparam streamId the stream to emit to 

19  * @param anchor the tuple to anchor to 

20  * @param tuple the new output tuple from this bolt 

21  * Qreturn the list of task ids that this new tuple was sent to 

22 */ 

23 public List<Integer> emit(String streamId, Tuple anchor, List«Object» tuple) { 
24 return emit(streamId, Arrays.asList(anchor), tuple); 

25 } 


27 public List<Integer> emit(String streamId, List«Object» tuple) { 
28 return emit(streamId, (List) null, tuple); 
29 } 


31 public List«Integer» emit(Collection«Tuple» anchors, List«Object» tuple) { 
32 return emit(Utils.DEFAULT STREAM ID, anchors, tuple); 
33 } 


36 public List«Integer» emit(Tuple anchor, List«Object» tuple) { 
37 return emit(Utils.DEFAULT STREAM ID, anchor, tuple); 
38 } 


40 public List«Integer» emit(List<Object> tuple) { 
41 return emit(Utils.DEFAULT STREAM ID, tuple); 
42 } 
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43 

44 [** 

45  * Emits a tuple directly to the specified task id on the specified stream. 

46 * If the target bolt does not subscribe to this bolt using a direct grouping, 
47  * the tuple will not be sent. If the specified output stream is not declared 
48  * as direct, or the target bolt subscribes with a non-direct grouping, 

49 * an error will occur at runtime. The emitted values must be 

50  * immutable. 

51 * 

52  * (param taskId the taskId to send the new tuple to 


53  * (param streamId the stream to send the tuple on. It must be declared as a direct stream in 
the topology definition. 

54  * @param anchor the tuple to anchor to 

55  * (param tuple the new output tuple from this bolt 

56 */ 

57 public void emitDirect(int taskId, String streamId, Tuple anchor, List«Object» tuple) ( 

58 emitDirect(taskId, streamId, Arrays.asList(anchor), tuple); 

59 j 


61 public void emitDirect(int taskId, String streamId, List«Object» tuple) { 
62 emitDirect(taskId, streamId, (List) null, tuple); 
63 } 


65 public void emitDirect(int taskId, Collection«Tuple» anchors, List«Object» tuple) { 
66 emitDirect(taskId, Utils.DEFAULT STREAM ID, anchors, tuple); 
67 } 


69 public void emitDirect(int taskId, Tuple anchor, List<Object> tuple) { 
70 emitDirect(taskId, Utils.DEFAULT STREAM ID, anchor, tuple); 
71 } 


74 public void emitDirect(int taskId, List<Object> tuple) { 
75 emitDirect(taskId, Utils.DEFAULT STREAM ID, tuple); 
76 } 


78 QOverride 

79 public List«Integer» emit(String streamId, Collection«Tuple» anchors, List«Object» tuple) ( 
80 return delegate.emit(streamId, anchors, tuple); 

81 } 


83 @Override 

84 public void emitDirect(int taskId, String streamId, Collection<Tuple> anchors, List<Object> tuple){ 
85 _delegate.emitDirect(taskId, streamId, anchors, tuple); 

86 } 


88 @Override 

89 public void ack(Tuple input) { 
90 _delegate.ack(input) ; 

91 } 


93 @Override 
94 public void fail(Tuple input) { 
95 . delegate.fail(input); 
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96 ) 

97 

98 GOverride 

99 public void reportError(Throwable error) ( 


100 . delegate.reportError(error); 
101 ) 
a 第 10~12 行 为 类 0utputCollector 的 构造 函数 ， 它 需要 传人 一 个 实现 了 IOutputCollector 的 


对 象 。 = 


O 第 23~42 行 定义 了 emit 的 各 种 重 载 方法 ， 有 具体 如 下 所 示 。 
a 若 未 传人 streamId， 使 用 default 作 为 流 号 。 
m 若 未 传人 anchor ， 使 用 对 象 nu11 作 为 标记 。 
m 若 传 人 的 anchor 不 是 列表 对 象 ， 将 其 转化 成 为 列表 对 象 。 
口 第 44~76 行 定义 了 emtiDirect 的 各 种 重 载 方法 ， 它 与 emit 方 法 很 类 似 。 
口 第 78~101 行 实现 了 IOutputCollector 接 口 ， 利 用 代理 对 象 实现 这 些 方法 。 


3.5.2 IBasicOutputCollector#BasicOutputCollector 


我 们 看 一 下 接口 IBasicOutputCollector 的 定义 : 


public interface IBasicOutputCollector { 
List<Integer> emit(String streamId, List«Object» tuple); 
void emitDirect(int taskId, String streamId, List«Object» tuple); 
void reportError(Throwable t); 


} 


首先 介绍 一 下 为 什么 会 有 IBasicOutputCollector。 这 个 接口 是 在 IBasicBolt 中 使 用 的 ， 对 比 
IOutputCollector 可 以 看 出 它们 的 区 别 。 
口 IBasicOutputCollector 没 有 Ack 和 Fail 方 法 。 
口 IBasicOutputCollector 的 emit 和 emitDirect 方 法 中 没有 anchor 人 参数 。 

这 样 设计 的 原因 是 如 果 使 用 IBasicBolt，Storm 框 架 会 自动 帮 用 户 进行 Ack、Fail 和 Anchor 操 
作 ， 用 户 自己 不 需要 关心 这 一 点 ， 后 面 介 绍 IBasicBolt 的 时 候 我 们 会 详细 介绍 这 一 点 。 所 以 为 了 
确保 这 种 机 制 正 常 运行 ,避免 用 户 在 使 用 时 出 错 ，Storm 提 全 eee 
当然 ， 简 化 也 就 意味 着 使 用 IBasicBolt 是 有 限制 的 ， 后 面 也 会 介绍 这 一 点 。 

BasicOutputCollector 是 Storm 提 供 Ec uu i due 其 中 包含 了 一 
个 OutputCollector 类 型 的 成 员 变量 ， 实 际 上 所 有 的 消息 最 终 都 将 由 这 个 OutputCollector 进 行 处 
理 。BasicOutputCollector 还 提供 了 一 些 简 易 的 方法 进行 消息 标记 。 下 面 简 单 分 析 如 下 : 


1 public class BasicOutputCollector implements IBasicOutputCollector { 
2 private OutputCollector out; 

3 private Tuple inputTuple; 

4 

5 public BasicOutputCollector(OutputCollector out) { 

6 this.out = out; 
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7 Jj 

8 

9 public List<Integer> emit(String streamId, List«Object» tuple) { 
10 return out.emit(streamId, inputTuple, tuple); 

11 } 

12 

13 public List<Integer> emit(List<Object> tuple) { 

14 return emit(Utils.DEFAULT STREAM ID, tuple); 

15 } 

16 

17 public void setContext(Tuple inputTuple) { 

18 this.inputTuple - inputTuple; 

19 ] 

20 

21 public void emitDirect(int taskId, String streamId, List«Object» tuple) { 
22 out.emitDirect(taskId, streamId, inputTuple, tuple); 
23. ] 

24 

25 public void emitDirect(int taskId, List«Object» tuple) { 
26 emitDirect(taskId, Utils.DEFAULT STREAM ID, tuple); 
27 ] 

28 

29 protected IOutputCollector getOutputter() { 

30 return out; 

31 } 

32 

33 public void reportError(Throwable t) { 

34 out.reportError(t); 

35 ] 

36 ) 


a 第 2 行 定 义 代理 的 out 对 象 ， 类 型 为 0utputCollector。 

a 第 3 行 定 义 输入 的 消息 ， 它 将 作为 消息 的 标记 对 象 ， 用 于 Ack 系 统 。 

O 第 9~15 行 定义 emit 方 法 以 及 重 载 ， 若 未 指定 streamId， 将 发 送 到 default 流 。 

口 第 17~19% 行 定义 setContext 方 法 ， 将 输入 的 消息 作为 上 下 文 。 若 未 重新 调用 该 函数 ， 则 接 
下 来 由 emit 发 送出 去 的 消息 都 以 该 消息 作为 标记 ， 也 即 都 是 由 该 消息 衍生 出 来 的 。 

口 第 21~27 行 定义 emitDirect 方 法 及 重 载 ， 若 未 指定 streamId， 将 发 送 到 default 流 。 


3.5.3 ”BatchOutputCollector 和 BatchOutputCollectorImp1 
BatchOutputCollector 是 Storm 中 用 于 数据 批 处 理 的 输出 收集 器 ， 它 的 定义 如 下 : 


public abstract class BatchOutputCollector ( 


/** 

* Emits a tuple to the default output stream. 

*/ 

public List«Integer» emit(List«Object» tuple) { 
return emit(Utils.DEFAULT STREAM ID, tuple); 

} 
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public abstract List«Integer» emit(String streamId, List«Object» tuple); 


/** 
* Emits a tuple to the specified task on the default output stream. This output 
* stream must have been declared as a direct stream, and the specified task must 
* use a direct grouping on this stream to receive the message. 
*/ 
public void emitDirect(int taskId, List«Object» tuple) { 

emitDirect(taskId, Utils.DEFAULT STREAM ID, tuple); 


} 


public abstract void emitDirect(int taskId, String streamId, List<Object> tuple); 


; public abstract void reportError(Throwable error); 

WW, EBUZJriSSRIBasicOutputCollectorrh;zE LAE TESLA, 3X HUNTER s 
而 且 ， 它 的 设计 思路 也 跟 IBasicOutputCollector 类 似 ， 常 用 在 IBatchBolt 中 ， 不 需要 自己 去 处 理 
Ack、Fail 和 Anchor 这 3 项 操作 ，Storm 框 架 默 认 实 现 了 这 些 操作 。 因 此 在 IBatchBolt 中 ， 用 户 只 需 
要 关心 数据 发 送 和 错误 处 理 即 可 。 

Storm 提 供 了 BatchOutputCollector 的 默认 实现 类 BatchoutputCollectorImp1， 它 实际 上 是 一 
个 代理 类 ， 内 部 封装 了 0utputCollector 变 量 ， 所 有 的 方法 都 通过 调用 0utputCollector 的 方法 来 
实现 ， 其 代码 如 下 : 


public class BatchOutputCollectorImpl extends BatchOutputCollector { 
OutputCollector collector; 


public BatchOutputCollectorImpl(OutputCollector collector) { 
collector - collector; 
) 


@Override 

public List<Integer> emit(String streamId, List<Object> tuple) { 
return collector.emit(streamId, tuple); 

} 


@Override 

public void emitDirect(int taskId, String streamId, List<Object> tuple) { 
_collector.emitDirect(taskId, streamId, tuple); 

} 


@Override 

public void reportError(Throwable error) { 
_collector.reportError(error) ; 

} 


public void ack(Tuple tup) { 
_collector.ack(tup) ; 
} 
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public void fail(Tuple tup) { 
_collector.fail(tup) ; 
} 


} 
ERX HA ack#llfail TENS, 它们 会 在 BatchBoltExecutor ( 3.8.4 节 将 介绍 ) 中 用 到 。 


3.5.4 ”Executor 中 的 I0utputCollector 实 现 


Executor 在 调用 Bolt 的 prepare 方 法 时 实现 了 IOutputCollector。 以 下 代码 来 源 于 executor.clj 文 件 : 


1 (OutputCollector. 

2 (reify IOutputCollector 

3 (emit [this stream anchors values] 

4 (bolt-emit stream anchors values nil)) 

5 (emitDirect [this task stream anchors values] 
6 (bolt-emit stream anchors values task)) 

7 (^void ack [this ^Tuple tuple] 

8 (let [^TupleImpl tuple tuple 

9 ack-val (.getAckVal tuple) ] 


10 (fast-map-iter [[root id] (.. tuple getMessageId getAnchorsTolds) ] 
11 (task/send-unanchored task-data 

12 ACKER-ACK-STREAM- ID 

13 [root (bit-xor id ack-val)]) 

14 )) 

15 (let [delta (tuple-time-delta! tuple)] 

16 (task/apply-hooks user-context .boltAck (BoltAckInfo. tuple task-id delta)) 
17 (when delta 

18 (builtin-metrics/bolt-acked-tuple! (:builtin-metrics task-data) 
19 executor-stats 

20 (.getSourceComponent tuple) 

21 (.getSourceStreamId tuple) 

22 delta) 

23 (stats/bolt-acked-tuple! executor-stats 

24 (.getSourceComponent tuple) 

25 (.getSourceStreamId tuple) 

26 delta)))) 

27 (void fail [this ^Tuple tuple] 

28 (fast-list-iter [root (.. tuple getMessageId getAnchors) ] 

29 (task/send-unanchored task-data 

30 ACKER-FAIL-STREAM-ID 

31 [root])) 

32 (let [delta (tuple-time-delta! tuple)] 

33 (task/apply-hooks user-context .boltFail (BoltFailInfo. tuple task-id delta)) 
34 (when delta 

35 (builtin-metrics/bolt-failed-tuple! (:builtin-metrics task-data) 
36 executor-stats 

37 (.getSourceComponent tuple) 

38 (.getSourceStreamId tuple)) 

39 (stats/bolt-failed-tuple! executor-stats 

40 (.getSourceComponent tuple) 


41 (.getSourceStreamId tuple) 
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42 delta)))) 

43  (xeportError [this error] 
44 (report-error error) 
45 )) 


O 第 2~45 行 实现 了 IOutputCollector 接 口 。 第 1 行 则 初始 化 了 一 个 OutputCollector 对 象 ， 这 
个 对 象 就 是 在 通常 的 用 户 代 码 中 看 到 的 对 象 ， 用 户 代 码 以 及 前 面 介 绍 过 的 各 种 输出 收集 
器 归根 到 底 都 会 使 用 该 对 象 来 向 外 发 送 数据 。 

O 第 3~4 行 实现 了 emit 方 法 , 其 数据 目标 的 TaskId 为 nil。 emit 方 法 主要 调用 clojure 的 bolt-emit 

函数 ， 该 函数 将 在 第 10 章 中 详细 介绍 。 

O 第 5~6 行 实现 了 emitDirect 方 法 ， 它 也 是 基于 bolt-emit 冰 数 来 实现 的 。 


3.6 组 件 接口 


组 件 接口 IComponent 定 义 了 如 下 两 个 方法 。 

口 declare0utputFields 方 法 : 用 于 定义 组 件 的 输出 Schema。 

口 getComponentConfiguration 方 法 : 用 来 描述 一 些 与 组 件 相 关 的 配置 。 
IComponent 主 要 用 于 构建 Topology， 所 有 的 Spout 和 Bolt 也 都 会 实现 该 接口 ， 其 代码 如 下 。 


/** 
* Common methods for all possible components in a topology. This interface is used 
* when defining topologies using the Java API. 
*/ 
public interface IComponent extends Serializable { 
void declareOutputFields(OutputFieldsDeclarer declarer); 
Map«String, Object» getComponentConfiguration(); 
】 


3.7 Spouti£H 


Storm 中 与 Spout 相 关 的 接口 主要 有 ISpout 和 IRichSspout， 图 3-2 描 述 了 它们 之 间 的 类 关系 。 


I ISpout 
a open(Map, TopologyContext, SpoutOutputCollector) void 
m dose) void —R 
w activate void 
a declareOutputFields(OutputFieldsDedarer) void 
im deactivate) void 
P. componentConfiguration Map<String, Object» 
a) nextTuple0 void 
a ack(Object) void 
a fail(Object) void 


1 IRichSpout 


图 3-2”Spout 接 口 类 关系 


36 第 3 章 Storm 编程 基础 


3.7.1 ISpout 
接口 ISpout 定 义 了 作为 Spout 应 该 实现 的 功能 集合 : 
/** 
* ISpout is the core interface for implementing spouts. A Spout is responsible 
* for feeding messages into the topology for processing. For every tuple emitted by 
* a spout, Storm will track the (potentially very large) DAG of tuples generated 
* based on a tuple emitted by the spout. When Storm detects that every tuple in 
* that DAG has been successfully processed, it will send an ack message to the Spout. 
* 
* <p>If a tuple fails to be fully process within the configured timeout for the 
* topology (see {@link backtype.storm.Config}), Storm will send a fail message to the spout 
* for the message.«/p» 
* 
* «p» When a Spout emits a tuple, it can tag the tuple with a message id. The message id 
* can be any type. When Storm acks or fails a message, it will pass back to the 
* spout the same message id to identify which tuple it's referring to. If the spout leaves out 
* the message id, or sets it to null, then Storm will not track the message and the spout 
* will not receive any ack or fail callbacks for the message.«/p» 
* 
* <p>Storm executes ack, fail, and nextTuple all on the same thread. This means that an implementor 
* of an ISpout does not need to worry about concurrency issues between those methods. However, it 
* also means that an implementor must ensure that nextTuple is non-blocking: otherwise 
* the method could block acks and fails that are pending to be processed.«/p» 
*/ 
public interface ISpout extends Serializable { 


/** 
* Called when a task for this component is initialized within a worker on the cluster. 
It provides the spout with the environment in which the spout executes. 


* 
* 
* «p»This includes the:«/p» 
* 
* 


Gparam conf The Storm configuration for this spout. This is the configuration provided to the 

topology merged in with cluster configuration on this machine. 

* (param context This object can be used to get information about this task's place within the 
topology, including the task id and component id of this task, input and output information,etc. 

* @param collector The collector is used to emit tuples from this spout. Tuples can be emitted at 
any time, including the open and close methods. The collector is thread-safe and should be 
saved as an instance variable of this spout object. 

*/ 

void open(Map conf, TopologyContext context, SpoutOutputCollector collector); 


Called when an ISpout is going to be shutdown. There is no guarentee that close 
will be called, because the supervisor kill -9's worker processes on the cluster. 


<p>The one context where close is guaranteed to be called is a topology is 
killed when running Storm in local mode.«/p» 

*/ 

void close(); 


/** 
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} 


* Called when a spout has been activated out of a deactivated mode. 

* nextTuple will be called on this spout soon. A spout can become activated 
* after having been deactivated when the topology is manipulated using the 
* "storm client. 

*/ 

void activate(); 


[** 

* Called when a spout has been deactivated. nextTuple will not be called while 
* a spout is deactivated. The spout may or may not be reactivated in the future. 
g 

void deactivate(); 


/** 

* When this method is called, Storm is requesting that the Spout emit tuples to the 

* output collector. This method should be non-blocking, so if the Spout has no tuples 

* to emit, this method should return. nextTuple, ack, and fail are all called in a tight 

* loop in a single thread in the spout task. When there are no tuples to emit, it is courteous 
* to have nextTuple sleep for a short amount of time (like a single millisecond) 
* so as not to waste too much CPU. 


void nextTuple(); 


/** 

* Storm has determined that the tuple emitted by this spout with the msgId identifier 
* has been fully processed. Typically, an implementation of this method will take that 
* message off the queue and prevent it from being replayed. 

*/ 

void ack(Object msgId); 


/** 

* The tuple emitted by this spout with the msgId identifier has failed to be 
* fully processed. Typically, an implementation of this method will put that 
* message back on the queue to be replayed at a later time. 

*/ 

void fail(Object msgId); 
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的 是 ， 由 于 nextTuple、ack 和 fail 方 法 是 在 一 个 线程 里 面 被 调用 的 ， 如 果 nextTuple 阻 蹇 ， 其 他 方 
法 也 将 被 阻塞 ， 这 样 会 有 许多 意外 情况 发 生 ， 因 此 nextTuple 必 须 是 非 阻塞 的 。 任 何 的 Spout 都 将 
利用 nextTuple 来 发 送信 息 。 

ISpout 的 fail 和 ack 回 调 方法 仅仅 给 出 了 发 送 消息 时 所 对 应 的 MessageId， 而 没有 给 出 具体 的 
消息 内 容 ， 这 就 意味 着 如 果 要 实现 消息 的 重 传 ， 用 户 则 需要 自己 来 维护 那些 已 经 发 送 的 消息 。 

当 Spout 被 设置 为 活跃 或 者 不 活跃 时 , 会 分 别 调用 active 回 调 方法 和 deactive 回 调 方法 将 该 状 


态 通知 给 用 户 代 码 。 这 样 当 Spout 处 于 非 活 跃 状态 时 ，nextTuple 不 会 被 调用 。 


在 实现 Spout 的 过 程 中 ， 用 户 可 以 编写 其 构造 函数 ， 然 而 该 构造 函数 并 不 会 被 实际 调用 。 
为 在 提交 Topology 时 ， 系 统 会 调用 Topology 的 构造 函数 ( 而 非 Spout 的 构造 图 数 )， 并 将 产生 的 对 
象 序列 化 成 字符 数组 。 每 一 个 节点 上 的 Spout 对 象 都 是 通过 反 序 列 化 得 到 的 ， 这 可 能 导致 某 些 成 
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员 没 有 被 正确 初始 化 。ISpout 中 的 open 回 调 函 数 会 在 对 象 被 反 序 列 后 调用 ， 我 们 应 当 在 open 方 法 
中 对 对 象 的 复杂 成 员 进行 初始 化 ， 而 不 应 使 用 构造 函数 来 完成 这 一 过 程 。 


3.7.2 IRichSpout 

IRichSspout 需 要 同时 实现 IComponent 和 ISpout 接 口 ， 于 是 从 含义 上 看 它 表示 一 个 具有 Spout 功 
能 的 组 件 ， 其 定义 如 下 : 

public interface IRichSpout extends ISpout, IComponent { 

} 

如 果 用 户 使 用 Java 来 构建 Topology，IRichspout 以 及 下 一 节 要 介绍 的 IRichBolt 是 用 来 编写 


Topology 组 件 的 主要 接口 。 
Storm 是 如 何以 及 何 时 调用 Spout 内 的 各 种 方法 呢 ? 这 将 在 第 10 章 中 详细 解释 。 


3.8 Bolt 接口 


Storm 中 定义 的 Bolt 接 口 主 要 有 IBolt 、IRichBolt 、IBasicBolt 和 IBatchBolt， 它 们 的 类 关系 
如 图 3-3 所 示 。 


1 IBolt 


1 IComponent 


a prepare(Map, TopologyContext, OutputCollector) void 
m dedareOutputFields(OutputFieldsDedarer) void 
im execute(Tuple) void 
P) componentConfiguration Map<String, Object 
S @ deanup0 void 
[ t + 
1 IBasicBolt | 1 IBatchBolt 
a prepare(Map, TopologyContext) void D) IRichBolt æ prepare(Map, TopologyContext, BatchOutputCollector, T) void 
a execute(Tuple, BasicOutputCollector) void A lY a execute(Tuple) void 
@ deanup0 void 1 H @ finishBatch0 void 
1 | 1 
1 L 
[a eee Pu 1 
1 
1 1 ! 
| © BatchBoltExecutor 
€. BasicBoltExecutor m) prepare(Map, TopologyContext, OutputCollector) void 
m dedareOutputFields(OutputFieldsDedarer) void $9 execute(Tuple) void 
im  prepare(Map, TopologyContext, OutputCollector) void m) deanup0 void 
m execute(Tuple) void im. finishedId(Object) void 
im deanup0 void m) timeoutId(Object) void 
fÐ componentConfiguration Map<String, Object» m) dedareOutputFields(OutputFieldsDedarer) void 
P componentConfiguration Map<String, Object» 
3 a Ly 
图 3-3 Bolt 接口 的 类 关系 


3.8.1 IBolt 
IBolt 定 义 了 Bolt 的 功能 集合 ， 其 代码 如 下 : 
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* 
* 


An IBolt represents a component that takes tuples as input and produces tuples 
as output. An IBolt can do everything from filtering to joining to functions 
to aggregations. It does not have to process a tuple immediately and may 

hold onto tuples to process later. 


«p»A bolt's lifecycle is as follows:«/p» 


«p»IBolt object created on client machine. The IBolt is serialized into the topology 
(using Java serialization) and submitted to the master machine of the cluster (Nimbus). 
Nimbus then launches workers which deserialize the object, call prepare on it, and then 
start processing tuples.«/p» 


«p»If you want to parameterize an IBolt, you should set the parameter's through its 
constructor and save the parameterization state as instance variables (which will 
then get serialized and shipped to every task executing this bolt across the cluster).«/p» 
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«p»When defining bolts in Java, you should use the IRichBolt interface which adds 
necessary methods for using the Java TopologyBuilder API.«/p» 

*/ 

public interface IBolt extends Serializable { 

/** 

* Called when a task for this component is initialized within a worker on the cluster. 
* It provides the bolt with the environment in which the bolt executes. 

* 


* «p»This includes the:«/p» 

* 

* @param stormConf The Storm configuration for this bolt. This is the configuration provided to 
the topology merged in with cluster configuration on this machine. 

* @param context This object can be used to get information about this task's place within the 
topology, including the task id and component id of this task, input and output information,etc. 

* @param collector The collector is used to emit tuples from this bolt. Tuples can be emitted at 
any time, including the prepare and cleanup methods. The collector is thread-safe and should 
be saved as an instance variable of this bolt object. 

i 

void prepare(Map stormConf, TopologyContext context, OutputCollector collector); 


* 
* 


Process a single tuple of input. The Tuple object contains metadata on it 
about which component/stream/task it came from. The values of the Tuple can 

be accessed using Tuple#getValue. The IBolt does not have to process the Tuple 
immediately. It is perfectly fine to hang onto a tuple and process it later 
(for instance, to do an aggregation or join). 


<p>Tuples should be emitted using the OutputCollector provided through the prepare method. 
It is required that all input tuples are acked or failed at some point using the OutputCollector. 
Otherwise, Storm will be unable to determine when tuples coming off the spouts 

have been completed.«/p» 


«p»For the common case of acking an input tuple at the end of the execute method, 
see IBasicBolt which automates this.«/p» 
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@param input The input tuple to be processed. 
*/ 
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void execute(Tuple input); 


4k 


Called when an IBolt is going to be shutdown. There is no guarentee that cleanup 
will be called, because the supervisor kill -9's worker processes on the cluster. 


<p>The one context where cleanup is guaranteed to be called is when a topology 
is killed when running Storm in local mode.</p> 


=. & 3b E 


*/ 
void cleanup(); 


} 


Bolt 是 Storm 中 的 基础 运行 单位 ， 当 其 启动 并 有 消息 输入 时 , 将 调用 execute 方 法 来 进行 处 理 。 
与 ISpout 类 似 ，IBolt 对 象 在 提交 时 也 会 被 序列 化 为 字 节 数组 ， 具 体 的 执行 节点 通过 反 序 列 化 的 
方法 得 到 该 对 象 ， 并 调用 prepare 回 调 方法 。 用 户 应 将 复杂 对 象 的 初始 化 放 在 prepare 回 调 方 法 中 
实现 ， 以 保证 每 个 具体 对 象 都 可 以 正确 初始 化 。 

对 象 被 销毁 时 ， 将 调用 cleanup 回 调 方法 ， 但 是 Storm 并 不 保证 该 方法 一 定 被 执行 。 
通常 ， 在 execute 方 法 的 实现 中 会 对 输入 消息 进行 处 理 ， 这 有 可 能 产生 新 消息 需要 发 送 到 下 
游 节 点 ， 最 后 还 要 对 输入 的 消息 进行 Ack 操 作 。 如 果 消 息 处 理 失败 ， 则 需 对 输入 的 消息 进行 Fail 
操作 ， 这 是 保证 Ack 消 息 系 统 可 以 正常 工作 的 基础 。 


3.8.2 IRichBolt 


IRichBolt 需 要 同时 实现 IComponent 以 及 IBolt 接 口 ,， 其 含义 是 一 个 具有 Bolt 功 能 的 组 件 。 EK 
际 使 用 中 ，IRichBolt 是 实现 Topology 组 件 的 主要 接口 ， 其 定义 如 下 : 


public interface IRichBolt extends IBolt, IComponent { 


} 


3.8.3 IBasicBolt 


IBasicBolt 接 口 的 定义 与 IBolt 基 本 一 致 ， 具 体 的 实现 要 求 也 与 IBolt 相 同 ， 它 与 IBolt 的 区 别 
在 于 以 下 两 点 。 
a 它 的 输出 收集 器 使 用 的 是 BasicOutputCollector, 并 且 该 参数 被 放 在 了 execute 方 法 中 而 不 
是 prepare 中 。 
口 它 实 现 了 IComponent 接 口 ， 这 表明 它 可 以 用 来 定义 Topology 组 件 。 
IBasicBolt 的 定义 如 下 : 


public interface IBasicBolt extends IComponent { 
void prepare(Map stormConf, TopologyContext context); 
/** 
* Process the input tuple and optionally emit new tuples based on the input tuple. 
* 


* All acking is managed for you. Throw a FailedException if you want to fail the tuple. 
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*/ 
void execute(Tuple input, BasicOutputCollector collector); 
void cleanup(); 


} 
这 里 解释 一 下 为 什么 会 有 这 个 接口 。IBasicBolt 的 主要 作用 是 为 用 户 提供 一 种 更 简单 的 Bolt 
编写 方式 。 基 于 IBasicBolt 编 写 的 好 处 是 Storm 框 架 本 身 帮 你 处 理 了 所 发 出 消息 的 Ack、Fail 和 
Anchor 操 作 ， 这 是 由 执行 器 BasicBoltExecutor 实 现 的 。 mE 
BasicBoltExecutor 实 现 了 IRichBolt 接 口 , 同时 还 包含 了 一 个 IBasciBolt 成 员 变量 用 于 调用 的 
转发 。 它 是 基于 装饰 模式 实现 的 ， 其 定义 如 下 : 


1 public class BasicBoltExecutor implements IRichBolt { 

2 public static Logger LOG = LoggerFactory.getLogger(BasicBoltExecutor.class) ; 
3 

4 private IBasicBolt bolt; 

5 private transient BasicOutputCollector collector; 

6 

7 public BasicBoltExecutor(IBasicBolt bolt) { 

8 bolt - bolt; 

9 } 

10 

11 public void declareOutputFields(OutputFieldsDeclarer declarer) { 
12 _bolt.declareOutputFields (declarer); 

13 ] 

14 

15 

16 public void prepare(Map stormConf, TopologyContext context, OutputCollector collector) { 
17 _bolt.prepare(stormConf, context); 

18 collector = new BasicOutputCollector(collector); 

19 } 

20 

21 public void execute(Tuple input) { 

22 _collector.setContext (input) ; 

23 try { 

24  bolt.execute(input, collector); 

25 . collector.getOutputter().ack(input); 

26 } catch(FailedException e) { 

27 if(e instanceof ReportedFailedException) { 

28 . collector.reportError(e); 

29 } 

30 _collector.getOutputter().fail(input) ; 

31 } 

32 } 

33 

34 public void cleanup() { 

35 _bolt.cleanup(); 

36 } 

37 

38 public Map<String, Object> getComponentConfiguration() { 
39 return _bolt.getComponentConfiguration(); 

40 } 
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a 第 4 行 定 义 了 成 员 变量 bolt， 它 实现 了 IBasicBolt 接 口 。 

口 第 5 行 定 义 了 成 员 变量 collector ， 它 实现 了 一 个 BasicOutputCollector 对 象 ， 该 对 象 提供 

了 一 些 易 用 方法 。 例 如 , 知 发 送 消息 时 未 指定 输出 流 , 它 会 将 消息 发 送 至 id 为 default 的 流 。 

O 第 11~13 行 实现 了 declare0utputFields 方 法 ， 它 实际 上 是 在 调用 _bolt 的 declareOutput 

Fields 方 法 。 

a 第 16~19 行 调用 _bolt 的 prepare 方 法 ， 并 实例 化 BasicOutputCollector。 

口 第 21~32 行 实现 了 execute 方 法 。 

a 第 22 行 设置 执行 器 运行 的 上 下 文 ， 它 表示 经 execute 方 法 发 送出 去 的 消息 都 是 由 输入 消息 
产生 的 , 即 输出 的 消息 都 将 标记 为 输入 消息 所 衍生 出 来 的 消息 , 这 是 使 用 IBasicBolt 消 息 
跟踪 的 重要 一 环 。 

口 第 24 行 调用 _bolt 的 execute 方 法 。 

O 第 25 行 对 输入 的 消息 进行 Ack 操 作 。 结 合 前 面 介绍 的 Basic0utputCollector 以 及 第 22 行 的 
设置 可 以 知道 ， 这 一 步 意 味 着 基于 当前 输入 消息 的 处 理 及 衍生 消息 的 发 送 已 经 完成 ， 此 
时 就 可 以 对 该 消息 进行 Ack 操 作 了 。 

O 第 26~31 行 中 ，Storm 捕 获 所 有 的 FailedException， 并 对 输入 的 消息 进行 Fail 操 作 。 如 果 捕 

获 的 异常 为 ReportedFailedException 实 例 ， 将 调用 reportError 回 调 方法 ， 给 用 户 一 个 机 
会 去 处 理 异常 。FailedException， 是 Storm 定 义 的 一 种 基本 异常 ， 用 来 进行 消息 的 失败 重 
发 、 事 务 的 失败 重 试 等 操作 ， 并 不 会 导致 Topology 停 止 运行 。 

用 户 实现 了 IBasicBolt 接 口 的 Bolt 对 象 以 后 ， 在 构建 Topology 时 ，Storm 会 调用 Topology 
Builder 的 setBolt 方 法 设置 该 Bolt 对 象 。SetBolt 方 法 会 用 BasicBoltExecutor 封 装 用 户 的 实现 类 ， 
这 是 Storm 自 动 帮 用 户 实现 的 ， 而 且 它 还 会 调用 可 接收 IRichBolt 参 数 的 重 载 方法 完成 Bolt 设 置 。 
同时 这 也 就 解释 了 BasicBoltExecutor 需 要 实现 IRichBolt 接 口 的 原因 。setBolt 方 法 的 代码 如 下 : 


public BoltDeclarer setBolt(String id, IBasicBolt bolt, Number parallelism hint) { 
return setBolt(id, new BasicBoltExecutor(bolt), parallelism hint); 
} 


public BoltDeclarer setBolt(String id, IRichBolt bolt, Number parallelism hint) { 
validateUnusedId(id); 
initCommon(id, bolt, parallelism hint); 
_bolts.put(id, bolt); 
return new BoltGetter(id); 


3.8.4 IBatchBolt 


区 别 于 IBasicBolt 接 口 ，IBatchBolt 主 要 用 于 Storm 中 的 批 处 理 。 目 前 ，Storm 主 要 用 该 接口 来 
实现 可 靠 的 消息 传输 ， 在 这 种 情况 下 ， 批 处 理会 比 单一 消息 处 理 更 为 高 效 。Storm 的 事务 Topology 
以 及 Trident 主 要 是 基于 IBatchBolt 的 。 相 比 前 面 的 IBolt 、IBasicBolt 和 IRichBolt，IBatchBolt 中 多 
了 一 个 finishBatch 方 法 ， 它 在 一 个 批 处 理 结束 时 被 调用 。 此 外 ，IBatchBolt 还 去 除了 cleanup 方 法 : 
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public interface IBatchBolt«T» extends Serializable, IComponent { 


void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, T id); 


void execute(Tuple tuple); 
void finishBatch(); 


public abstract class BaseBatchBolt<T> extends BaseComponent implements IBatchBolt«T» { } 
public abstract class BaseTransactionalBolt extends BaseBatchBolt«TransactionAttempt» ( j 


IBatchBolt 主 要 定义 了 3 个 方法 ， 如 下 所 示 。 


O prepare 方 法 : 用 来 初始 化 一 个 Batch。 值 得 注意 的 是 ， 在 prepare 方 法 中 ， 最 后 一 个 参数 是 


通用 类 型 T, 它 可 以 用 作 该 Batch 的 唯一 标识 。 在 IBatchBolt 衍 生 的 BaseTransactionalBolt 中 ， 


T 将 被 实例 化 为 TransactionalAttempt。 在 目前 的 Storm 实 现 中 , 每 个 事务 都 会 对 应 一 个 Batch， 
而 每 个 Batch 的 数据 都 会 由 一 个 新 创建 的 IBatchBolt 对 象 进行 处 理 。 于 是 在 prepare 方 法 中 ， 

需要 传人 一 个 用 于 标识 batch 的 变量 T。 MEEA Topology , Storm 则 利用 TransactionAttempt 
作为 标识 。 当 一 个 Batch 被 成 功 处 理 之 后 ， 该 Batch 对 应 的 IBatchBolt 对 象 将 被 销毁 ， 因 此 用 


户 不 能 通过 IBatchBolt 对 象 自 身 保 存 需 要 在 多 个 Batch 间 进行 共享 的 数据 。 
口 execute 方 法 : 用 于 处 理 属于 该 Batch 的 消息 。 


口 finishBatch 方 法 : 该 方法 仅 当 这 批 消息 被 处 理 完 时 才 会 被 调用 。 如 果 BatchBolt 同 时 实现 


了 ICommitter 的 接口 , finishBatch 方 法 只 有 当 该 Batch 之 前 的 所 有 Batch 均 被 成 功 处 理 后 才 


被 调用 。 这 既 保 证 了 强 序 关系 ， 同 时 也 是 Storm 中 事务 Topology 的 实现 基础 。 


证 finishBatch 会 在 这 批 消息 均 被 处 理 过 后 才 调用 ， 将 在 第 15 章 中 详细 介绍 。 


跟 IBasicBolt 类 似 ， 使 用 IBatchBolt 接 口 的 用 户 不 需要 关心 何 时 该 对 收 到 的 消 ) 


至 于 如 何 保 


息 进行 Ack、 


Fail 和 Anchor 操 作 ，Storm 框 架 内 部 通过 BatchBoltExecutor 自 动 帮 有 我 们 实现 了 这 些 功能 。 
BatchBoltExecutor 也 实现 了 IRichBolt 接 口 , 它 会 为 每 个 Batch 创 建 与 之 相对 应 的 BatchBolt 对 象 ， 

所 有 属于 该 Batch 的 消息 都 会 使 用 对 应 的 BatchBolt 对 象 来 处 理 。 同 时, 它 还 实现 了 FinishedCallback 

和 TimeoutCallback 接 口 , 这 两 个 接口 的 作用 我 们 会 在 后 面 给 予 介绍 。BatchBoltExecutor 的 实现 如 下 : 


public class BatchBoltExecutor implements IRichBolt, FinishedCallback, TimeoutCallback { 


public static Logger LOG = LoggerFactory.getLogger(BatchBoltExecutor.class) ; 


1 
2 
3 
4 byte[] _boltSer; 

5 Map<Object, IBatchBolt»  openTransactions; 
6 Map conf; 

7 TopologyContext context; 

8 BatchOutputCollectorImpl collector; 


9 

10 public BatchBoltExecutor(IBatchBolt bolt) { 
11 _boltSer = Utils.serialize(bolt); 

12 } 

13 


14 @Override 


15 public void prepare(Map conf, TopologyContext context, OutputCollector collector) { 


16 _conf = conf; 
17 context = context; 
18 _collector = new BatchOutputCollectorImpl(collector); 
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19  openTransactions = new HashMap<Object, IBatchBolt>(); 
20 } 


22 @Override 
23 public void execute(Tuple input) { 


24 Object id = input.getValue(0); 

25 IBatchBolt bolt = getBatchBolt(id); 
26 try { 

27 bolt.execute(input) ; 

28 _collector.ack(input) ; 

29 } catch(FailedException e) { 

30 LOG.error("Failed to process tuple in batch", e); 
31 _collector.fail(input) ; 

32 } 

33} 

34 


35 GOverride 
36 public void cleanup() ( 
37 } 


39 GOverride 
40 public void finishedId(Object id) { 


41 IBatchBolt bolt - getBatchBolt(id); 
42 _openTransactions.remove(id) ; 

43 bolt. finishBatch(); 

44 } 

45 


46 @Override 

47 public void timeoutId(Object attempt) { 
48 _openTransactions.remove(attempt) ; 
49 } 


52 @Override 

53 public void declareOutputFields(OutputFieldsDeclarer declarer) { 
54 newTransactionalBolt().declareOutputFields(declarer); 
55} 


57 @Override 
58 public Map<String, Object> getComponentConfiguration() { 


59 return newTransactionalBolt().getComponentConfiguration() ; 
60 } 

61 

62 private IBatchBolt getBatchBolt(Object id) { 

63 IBatchBolt bolt = _openTransactions.get(id) ; 

64 if(bolt--null) { 

65 bolt = newTransactionalBolt(); 

66 bolt.prepare( conf, context, collector, id); 
67  openTransactions.put(id, bolt); 

68 } 

69 return bolt; 

70 } 

71 


72 private IBatchBolt newTransactionalBolt() { 
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73 return (IBatchBolt) Utils.deserialize( boltSer); 


O 第 4 行 表示 了 内 含 BatchBolt 对 象 的 序列 化 字 节 数组 。 

O 第 23~33 行 实现 了 execute 方 法 ， 它 规定 输入 消息 的 第 1 列 用 于 标识 Batch 的 这。 在 事务 
Topology 中 ， 输 入 消息 的 第 1 列 为 TransactionAttempt 对 象 。 第 25 行 根据 BatchId 去 获得 一 
个 BatchBolt 对 象 。 第 28 行 对 输入 的 消息 进行 Ack 操 作 。 第 29~32 行 对 捕获 的 Failed 
Exception 进 行 处 理 ， 并 对 输入 的 消息 进行 Fail 操 作 。 

O 第 40~44 行 实现 了 FinishedCallback 接 口 , 这 里 将 调用 finishBatch 方 法 清理 Batch 对 象 。 可 
以 看 到 ，BatchBolt 对 象 在 不 同 的 Batch 之 间 是 不 重复 使 用 的 。 只 要 在 属于 某 Batch 的 消息 
均 被 处 理 后 ，finishBatch 方 法 才 可 以 被 调用 。 关 于 finishBatch 调 用 时 机 ， 也 将 在 第 15 章 
中 进行 分 析 。 

口 第 47~49 行 实现 TimeoutCallback 接 口 ， 它 仅仅 将 缓存 的 BatchBolt 对 象 删除 ， 这 对 于 清理 

不 再 使 用 的 BatchBolt 对 象 是 很 关键 的 。 关 于 其 调用 时 机 ， 将 在 第 15 章 进行 分 析 。 

口 第 72~74 行 通过 反 序 列 化 生成 一 个 IBatchBolt 对 象 。 

口 第 62~70 行 根据 BatchId 获 得 一 个 BatchBolt。 类 成 员 变量 openTransactions 用 来 存储 从 每 
一 个 BatchId 到 BatchBolt 的 对 应 关系 。 如 果 BatchId 对 应 的 BatchBolt 并 不 存在 ， 
getBatchBolt 方 法 将 调用 newTransactionalBolt 生 成 一 个 。 第 66 行 调用 新 创建 的 BatchBolt 
的 prepare 方 法 。 

理解 TBatchBolt 的 生命 周期 是 很 关键 的 。IBatchBolt 在 系统 收 到 属于 某 Batch 的 第 一 条 消息 时 

被 创建 ， 而 在 所 有 的 消息 都 处 理 完 成 之 后 再 被 销毁 。Storm 中 采用 反 序 列 化 对 象 的 方式 来 弥补 不 

斯 创建 IBatchBolt 对 象 所 带 来 的 负担 。 


3.8.5 ”小结 


这 一 节 主 要 介绍 了 Storm 中 几 种 基本 的 Bolt 接 口 ， 这 里 简单 总 结 一 下 。 

口 IRichBolt: Storm 中 最 常用 来 定义 Topology 组 件 的 接口 。 它 十 分 灵活 ， 用 户 可 以 通过 其 实 

现 各 种 控制 逻辑 ， 并 且 能 控制 何 时 进行 Ack、Fail 和 Anchor 操 作 。 

口 IBasicBolt: Storm 中 提供 的 定义 简单 逻辑 的 Topology 组 件 接 口 。 对 于 这 种 Bolt，Storm 内 
置 实现 了 Ack、Fail 和 Anchor 的 机 制 ， 用 户 基于 它 实 现 自己 的 Bolt 也 比较 简单 。 但 是 它 的 

使 用 是 有 限制 的 ， 基 于 收 到 的 某 条 消息 衍生 出 来 的 所 有 消息 必须 在 一 次 execute 中 发 送出 
去 (或 者 需要 对 消息 进行 缓存 并 且 编 号 ， 参 考 第 27 章 )， 和 否则 内 置 的 Ack 机 制 将 不 能 保证 
Bolt 的 正常 工作 。 所 以 ， 用 户 应 该 避免 使 用 该 类 型 的 Bolt 来 做 诸如 聚集 或 者 连接 的 操作 。 

口 IBatchBolt: 它 是 Storm 提 供 的 用 来 处 理 批 量 数据 的 接口 。 目 前 ， 它 只 用 于 事务 Topology 
中 ， 它 是 Storm 实 现 事务 Topology 的 基础 。 
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3.9 Storm 数据 结构 


storm.thrift 文 件 定义 了 Storm 中 用 到 的 最 底层 的 数据 结构 。Thrift 是 Apache 下 面 的 跨 语言 框架 ， 
它 可 以 基于 Thrift 定 义 文件 产生 不 同 语言 的 代码 。 关 于 Thrift 的 详细 内 容 , 请 访问 http://thrift.apache. 
org/ 进 行 学 习 。 下 面 我 们 来 看 一 下 Storm 中 使 用 的 Thrift 数 据 结构 的 定义 。 


3.9.1 GlobalStreamId 
GlobalStreamId 结 构 的 定义 如 下 所 示 : 


struct GlobalStreamId { 
1: required string componentId; 
2: required string streamId; 
#Going to need to add an enum for the stream type (NORMAL or FAILURE) 


在 Storm 中 , jii (stream) 是 一 个 非常 重要 的 概念 。 流 可 以 理解 为 消息 的 渠道 ,每 种 类 型 的 消 
息 可 以 用 一 个 流 来 表示 。 组 件 可 以 向 多 个 流 发 送 消息 , 也 可 以 从 多 个 流 接收 消息 。 GlobalStreamId 
用 来 标记 每 一 个 组 件 的 流 信 息 ， 它 含有 两 个 域 ， 一 个 为 componentId， 表 示 该 流 属于 哪个 组 件 ; 
另外 一 个 是 streamId， 它 是 流 的 标识 。 不 同 的 组 件 之 间 可 以 使 用 相同 的 streamId， 例 如 在 默认 情 
况 下 ， 用 户 接收 和 发 送 的 数据 均 来 自 于 streamId 为 default 的 流 ， 只 不 过 它们 隶属 于 不 同 的 组 件 。 


3.9.2 ”消息 分 组 方式 


分 组 方式 决定 了 组 件 所 发 送 的 消息 将 以 何 种 方式 到 达 接 收 端 ， 这 是 Storm 具 有 可 扩展 性 的 基 
mh. Ban, 使 用 随机 分 组 ,节点 可 以 发 送 一 组 消息 到 下 游 的 多 个 方 点 ,每 个 节点 收 到 这 组 消息 的 
一 部 分 ， 而 且 这 些 节 点 可 以 分 布 在 不 同 的 机 器 上 ， 从 而 达到 了 并 行 处 理 的 目的 。Grouping 的 定义 
如 下 所 示 : 


union Grouping { 
1: list<string> fields; //empty list means global grouping 
2: NullStruct shuffle; // tuple is sent to random task 
3: NullStruct all; // tuple is sent to every task 
4: NullStruct none; // tuple is sent to a single task (storm's choice) -» allows storm to optimize 
the topology by bundling tasks into a single process 
NullStruct direct; // this bolt expects the source bolt to send tuples directly to it 
JavaObject custom object; 
binary custom serialized; 
: NullStruct local or shuffle; // prefer sending to tasks in the same worker process, otherwise 
shuffle 


oN Ov un 


} 
Grouping 被 定义 为 union 类 型 ， 即 表示 市 点 之 间 只 能 采取 一 种 分 组 方式 。 
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3.9.3 StreamInfo 


StreamInfo 含 有 两 个 数据 成 员 ， 一 个 表示 输出 的 字段 名 列表 ， 另 一 个 则 表示 是 否 为 直接 流 。 
目前 ，Storm 限 制 只 有 直接 流 才能 采用 直接 分 组 方式 。StreamInfo 的 定义 如 下 : 


struct StreamInfo { 
1: required list«string» output fields; 
2: required bool direct; 


3.9.4 ShellComponent 
She11Component 结 构 用 于 与 非 Java 语 言 的 交互 ， 目 前 通过 标准 输入 输出 来 交换 数据 ; 


struct ShellComponent ( 
// should change this to 1: required list«string» execution command; 
1: string execution command; 
2: string script; 


3.9.5 ComponentObject 


Component0bject 是 一 个 联合 体 , 它 或 者 为 串 行 化 后 的 Java 对 象 , 或 者 为 shellComponent 对 象 ， 
抑或 为 Java 对 象 。 通 常 ， 第 一 种 和 第 三 种 更 为 常见 。 该 联合 体 的 定义 如 下 : 


union ComponentObject { 
1: binary serialized java; 
2: ShellComponent shell; 
3: JavaObject java object; 


3.9.6 ComponentCommon 


ComponentCommon 是 用 来 表示 Topology 的 基础 对 象 , 通过 使 用 TopologyBuilder 对 象 可 更 加 方便 
地 创建 这 个 数据 结构 。 后 面 我 们 会 进一步 讨论 TopologyBuilder。ComponentCommon 的 定义 如 下 : 


struct ComponentCommon { 
1: required map«GlobalStreamId, Grouping> inputs; 
2: required map«string, StreamInfo» streams; //key is stream id 
3: optional i32 parallelism hint; //how many threads across the cluster should be dedicated to this 
component 


// component specific configuration respects: 

// topology.debug: false 

// topology.max.task.parallelism: null // can replace isDistributed with this 
// topology.max.spout.pending: null 
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// topology.kryo.register // this is the only additive one 


// component specific configuration 

4: optional string json conf; 
} 
O inputs: 表示 该 组 件 将 从 哪些 GlobalSstreamId 以 何 种 分 组 方式 接收 数据 ， 其 中 GlobalstreamId 
即 为 某 个 组 件 上 面 定义 的 一 个 流 。 
O streams: 表示 该 组 件 要 输出 的 所 有 流 。 它 给 定 了 streamId 以 及 StreamInfo。 在 StreamInfo 
H, 我 们 定义 了 每 个 输出 流 的 字段 名 列表 ， 以 及 该 流 的 消息 分 组 是 否 为 直接 分 组 方式 。 
O parallelism hint: 表示 组 件 的 并 行 度 ， 即 有 多 少 个 线程 。 要 注意 ， 这 些 线程 可 能 分 布 在 
不 同 的 机 需 以 及 进程 空间 中 ， 其 默认 值 为 1。 
口 json_conf: 保存 与 该 组 件 相关 的 设置 ， 它 可 设置 的 参数 如 表 3-1 所 示 。 


表 3-1 组 件 的 配置 项 
BRAM a X 
topology. debug 设置 为 true 时 ，Storm 会 打印 出 所 有 发 送出 去 的 消息 ， 包 括 系统 消息 ， 例 如 Ack 消 息 
topology.max.task.parallelism ”任务 的 最 大 并 行 度 ， 通 常用 于 测试 
topology.max. spout . pending 仅仅 作用 于 每 个 Spout 节 点 ， 表 示 最 多 能 有 多 少 没 被 Ack 或 Fail 的 消息 在 系统 中 运行 。 
若 超出 此 限制 ，Spout 将 转 和 非 活跃 状态 ， 即 不 会 有 新 的 消息 发 送出 来 。 
只 有 发 送 的 消息 指定 了 messageId 时 ， 该 参数 才 会 生效 。messageId 也 是 Ack 系 统 正 常 工 
作 所 必需 的 
topology.kryo.register kryo 序 列 化 的 注册 列表 。 它 是 Storm 底 层 的 序列 化 框架 
( https://github.com/EsotericSoftware/kryo ) 
该 列表 的 内 容 可 以 是 类 的 名 称 ，kryo 会 根据 该 类 名 称 自动 序列 化 所 有 对 象 的 成 员 变 
量 ， 也 可 以 是 一 个 实现 了 com.esotericsoftware.kryo.Serializer 的 类 名 称 


IHI 


3.9.7 SpoutSpec 


SpoutSpec 包 含 两 个 成 员 ， 一 个 为 实现 具体 Spout 慑 辑 的 spout_object 对 象 ， 另 外 一 个 是 用 来 
描述 其 输入 输出 的 common 对 象 。 有 时 可 以 将 Spout 设 置 为 单 点 的 ， 如 事务 Topology 中 的 协调 Spout 
节点 。 可 以 通过 设置 topology.max.task.parallelism 人 参数 进行 控制 。SpoutSspec 的 定义 如 下 所 示 : 


struct SpoutSpec { 
1: required ComponentObject spout object; 
2: required ComponentCommon common; 
// can force a spout to be non-distributed by overriding the component configuration 
// and setting TOPOLOGY MAX TASK PARALLELISM to 1 


3.9.8 Bolt 
Bolt 的 数据 结构 与 SpoutSspec 是 一 致 的 ， 其 中 包含 两 个 成 员 ，bolt_object 是 包含 具体 逻辑 的 
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对 象 ，common 则 描述 了 输入 输出 : 


struct Bolt ( 
1: required ComponentObject bolt object; 
2: required ComponentCommon common; 


3.9.9 StormTopology 


StormTopolgy 用 于 描述 Topology 的 组 成 ， 它 包含 了 一 些 Spoutspec 和 Bolt， 每 个 SpoutSpec 或 
Bolt 都 会 有 一 个 全 局 唯一 的 名 字 。 目 前 ，state_spouts 基 本 上 没有 用 到 。 


struct StormTopology { 
//ids must be unique across maps 
// #workers to use is in conf 
1: required map«string, SpoutSpec» spouts; 
2: required map«string, Bolt» bolts; 
3: required map«string, StateSpoutSpec» state spouts; 


3.9.10 TopologySummary 


TopologySummary 描 述 了 由 用 户 提 交 的 Topology 的 基本 情况 ， 例 如 Topology 分 布 在 多 少 个 


Worker 上 面 ， 使 用 了 多 少 个 Executor， 以 及 一 共有 多 少 个 Task 等 。 
用 ， 以 返回 UTI 请求 的 数据 ， 其 定义 如 下 : 


struct TopologySummary { 

1: required string id; 
required string name; 
required i32 num tasks; 
required i32 num executors; 
required i32 num workers; 
required i32 uptime secs; 
required string status; 


Nou PWN 


3.9.11 SupervisorSummary 


这 个 数据 结构 主要 供 


and 


SupervisorSummary 描 述 了 每 一 个 Supervisor 的 基本 信息 。 这 里 Supervisor 代 表 了 机 器 ， 一 
Supervisor 上 可 以 启动 多 个 Worker ( 通常 为 4 个 )， 每 个 Worker 上 面 又 可 以 启动 多 个 Executor。 这 个 
数据 结构 也 是 在 Nimbus 返 回 UI 请 求 的 数据 时 会 被 用 到 ， 其 中 num_used_workers 表 示 已 经 占用 的 


Worker 数 目 ， 其 定义 如 下 : 


struct SupervisorSummary { 
1: required string host; 


50 第 3 章 Storm 编程 基础 


: required i32 uptime secs; 
required i32 num workers; 
required i32 num used workers; 
required string supervisor id; 


up Uu N.N 


3.9.12 ClusterSummary 


ClusterSummary 保 存 了 集群 中 所 包含 的 Supervisor 的 数目 及 其 基本 信息 ,还 保存 了 正在 集群 上 运 
行 的 Topology 的 基本 信息 。 Nimbus 在 返回 Storm UI 请求 的 数据 时 也 会 用 到 该 数据 结构 。 其 定义 如 下 : 


struct ClusterSummary { 
1: required list«SupervisorSummary» supervisors; 
2: required i32 nimbus uptime secs; 
3: required list«TopologySummary» topologies; 


3.9.13 BoltStats 


BoltSstats 结 构 用 于 Bolt 的 运行 统计 ， 其 定义 如 下 : 


struct BoltStats { 
1: required map«string, map«GlobalStreamId, i64>> acked; 
required map«string, map«GlobalStreamId, i64»» failed; 
required map«string, map«GlobalStreamId, double»» process ms avg; 
required map«string, map«GlobalStreamId, i64»» executed; 
required map«string, map«GlobalStreamId, double»» execute ms avg; 


up Uu N.N 


3.9.14 SpoutStats 


Spoutstats 用 于 Spout 的 运行 统计 ， 其 定义 如 下 : 


struct SpoutStats { 
1: required map«string, map«string, i64>> acked; 
2: required map«string, map«string, i64»» failed; 
3: required map«string, map«string, double»» complete ms avg; 


} 


3.9.15 ”统计 信息 
下 面 的 数据 结构 包含 了 在 Storm UI 上 显示 的 数据 ,例如 每 个 Executor 发 送 及 传输 消息 的 数目 等 : 


union ExecutorSpecificStats { 
1: BoltStats bolt; 
2: SpoutStats spout; 
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} 


// Stats are a map from the time window (all time or a number indicating number of seconds in the window) 
// to the stats. Usually stats are a stream id to a count or average. 
struct ExecutorStats { 
1: required map<string, map<string, i64»» emitted; 
2: required map<string, map<string, i64»» transferred; 
3: required ExecutorSpecificStats specific; 
| a 
struct ExecutorInfo ( 


1: required i32 task start; 
2: required i32 task end; 


struct ExecutorSummary { 
1: required ExecutorInfo executor info; 
2: required string component id; 
3: required string host; 
4: required i32 port; 
5: required i32 uptime secs; 
7: optional ExecutorStats stats; 


} 


struct TopologyInfo { 
1: required string id; 
2: required string name; 
3: required i32 uptime secs; 
4: required list«ExecutorSummary» executors; 
5: required string status; 
6: required map«string, list«ErrorInfo»» errors; 


3.9.06 DRPC 


DRPCRequest 定 义 了 DRPC 请 求 的 数据 结构 ， 它 包含 函数 的 参数 列表 func_args 以 及 请 求 的 
request_id。 由 于 在 获取 请 求 时 需要 传人 函数 名 ， 所 以 DRPCRequest 对 象 中 并 不 包含 函数 名 。 

DRPCExecutionException 是 异常 类 型 ， 它 在 处 理 请 求 失败 或 者 超时 时 会 用 到 ， 它 会 采用 不 同 
的 出 错 消息 msg 对 不 同 异常 状况 进行 区 分 。 

DistributedRPC 和 Distribute RPCInvocations 均 为 服务 类 型 ,它们 描述 了 DRPC 服 务 器 提供 的 
服务 接口 ， 可 以 用 于 产生 服务 器 的 访问 代码 。 它 们 的 区 别 在 于 前 者 负责 处 理 用 户 请 求 , 后 者 则 供 
DRPC Spout 获 取 请 求 或 供 Bolt 向 DRPC 服 务 器 发 送 结果 。DRPCRequest 的 定义 如 下 : 


struct DRPCRequest { 
1: required string func args; 
2: required string request id; 


} 


exception DRPCExecutionException { 
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1: required string msg; 


) 


service DistributedRPC { 
string execute(1: string functionName, 2: string funcArgs) throws (1: DRPCExecutionException e); 
} 


service DistributedRPCInvocations { 
void result(1: string id, 2: string result); 
DRPCRequest fetchRequest(1: string functionName); 
void failRequest(1: string id); 


3.10 ”基本 Topology 构建 器 


这 一 节 主 要 介绍 TopologyBuilder 以 及 它 所 提供 的 配置 声明 和 组 件 声明 的 实现 类 ,最 后 结合 一 
个 例子 来 解释 它 的 用 法 。 


3.10.1 TopologyBuilder 


TopologyBuilder 是 一 个 工具 类 ， 用 于 构建 Topology。 在 Storm 中 ，Topology 实 际 上 是 Thrift 的 
数据 结构 , 其 过 于 描述 化 的 特性 并 不 便于 我 们 使 用 , 而 TopologyBuilder 提 供 了 更 为 方便 的 构建 方 
法 。 它 的 主要 方法 有 setspout 、setBolt 以 及 它们 的 重 载 方法 。 其 最 终 目 的 是 创建 前 面 介绍 过 的 
StormTopology 对 象 。 仔 细 阅 读 代 码 中 的 注释 对 理解 代码 是 很 有 帮助 的 。TopologyBuilder 类 的 定 
义 如 下 : 


1 public class TopologyBuilder { 

2 private Map«String, IRichBolt» bolts - new HashMap«String, IRichBolt»(); 

3 private Map<String, IRichSpout> spouts = new HashMap«String, IRichSpout»(); 

4 private Map<String, ComponentCommon» commons = new HashMap«String, ComponentCommon»(); 

5 private Map«String, StateSpoutSpec» _stateSpouts = new HashMap«String, StateSpoutSpec>(); 
6 
7 
8 
9 


public StormTopology createTopology() { 
Map«String, Bolt» boltSpecs = new HashMap«String, Bolt>(); 
Map«String, SpoutSpec» spoutSpecs = new HashMap«String, SpoutSpec>(); 


10 for(String boltId: _bolts.keySet()) { 

11 IRichBolt bolt = bolts.get(boltId); 

12 ComponentCommon common - getComponentCommon(boltId, bolt); 

13 boltSpecs.put(boltId, new Bolt(ComponentObject.serialized java(Utils.serialize 

(bolt)),common)); 

14 } 

15 for(String spoutId: _spouts.keySet()) { 

16 IRichSpout spout = _spouts.get(spoutId) ; 

17 ComponentCommon common = getComponentCommon(spoutId, spout); 

18 spoutSpecs.put(spoutId, new SpoutSpec(ComponentObject.serialized_java(Utils. 
serialize(spout)), common) ); 

19 

20 } 


21 return new StormTopology(spoutSpecs, 
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22 boltSpecs, 

23 new HashMap«String, StateSpoutSpec»()); 

24 } 

25 

26 public BoltDeclarer setBolt(String id, IRichBolt bolt) { 

27 return setBolt(id, bolt, null); 

28 } 

29 

30 /** 

31 * Define a new bolt in this topology with the specified amount of parallelism. 
32 * 

33 * @param id the id of this component. This id is referenced by other components that want to 


consume this bolt's outputs. 

34 * @param bolt the bolt 

35 * param parallelism hint the number of tasks that should be assigned to execute this bolt. 
Each task will run on a thread in a process somewhere around the cluster. 

36 * @return use the returned object to declare the inputs to this component 

37 "f 

38 public BoltDeclarer setBolt(String id, IRichBolt bolt, Number parallelism hint) { 

39 validateUnusedId(id); 


40 initCommon(id, bolt, parallelism hint); 

41 _bolts.put(id, bolt); 

42 return new BoltGetter(id); 

43 ] 

44 

45 public BoltDeclarer setBolt(String id, IBasicBolt bolt) ( 

46 return setBolt(id, bolt, null); 

4 j 

48 

49 public BoltDeclarer setBolt(String id, IBasicBolt bolt, Number parallelism hint) { 
50 return setBolt(id, new BasicBoltExecutor(bolt), parallelism hint); 

51 jJ 

52 

53 ** 

54 * Define a new spout in this topology. 

55 * 

56 * @param id the id of this component. This id is referenced by other components that want 


to consume this spout's outputs. 
57 * @param spout the spout 


58 */ 

59 public SpoutDeclarer setSpout(String id, IRichSpout spout) { 

60 return setSpout(id, spout, null); 

61 } 

62 

63 /** 

64 * Define a new spout in this topology with the specified parallelism. If the spout declares 
65 * itself as non-distributed, the parallelism hint will be ignored and only one task 

66 * will be allocated to this component. 

67 i: 

68 * (param id the id of this component. This id is referenced by other components that want 


to consume this spout's outputs. 
69 * Qparam parallelism hint the number of tasks that should be assigned to execute this 
spout. Each task will run on a thread in a process somwehere around the cluster. 
70 * (param spout the spout 


54 


第 3 章 Storm 编程 基础 


71 un 
72 public SpoutDeclarer setSpout(String id, IRichSpout spout, Number parallelism hint) { 
73 validateUnusedId(id); 


74 initCommon(id, spout, parallelism hint); 
75 _spouts.put(id, spout); 

76 return new SpoutGetter(id) ; 

7 ] 

78 


79 private void validateUnusedId(String id) ( 
80 if( bolts.containsKey(id)) { 


81 throw new IllegalArgumentException("Bolt has already been declared for id " + id); 
82 ) 

83 if( spouts.containsKey(id)) { 

84 throw new IllegalArgumentException("Spout has already been declared for id " + id); 
85 

86 if( stateSpouts.containsKey(id)) { 

87 throw new IllegalArgumentException("State spout has already been declared for id"+id); 
88 } 

89 } 

90 

91 private ComponentCommon getComponentCommon(String id, IComponent component) { 

92 ComponentCommon ret = new ComponentCommon( commons.get(id)); 

93 


94 OutputFieldsGetter getter - new OutputFieldsGetter(); 

95 component.declareOutputFields(getter); 

96 ret.set streams(getter.getFieldsDeclaration()); 

97 return ret; 

98 ] 

99 

100 private void initCommon(String id, IComponent component, Number parallelism) ( 
101 ComponentCommon common - new ComponentCommon(); 

102 common.set inputs(new HashMap«GlobalStreamId, Grouping>()); 

103 if(parallelism!-null) common.set parallelism hint(parallelism.intValue()); 
104 Map conf = component.getComponentConfiguration(); 

105 if(conf!-null) common.set json conf(JSONValue.toJSONString(conf)); 

106 | commons.put(id, common); 

107 } 

108 } 


O 第 2~5 行 定义 了 类 成 员 变 量 。_bolts 包 含 了 所 有 的 Bolt 对 象 ， 它 们 均 为 IRichBolt 类 型 。 
_spout 包 含 了 所 有 的 Spout 对 象 ， 均 为 IRichspout 类 型 。_commons 则 包含 了 所 有 的 Bolt 及 
Spout 对 象 。stateSpouts 包 含 了 StateSpout 对 象 ,StateSpout 是 具有 同步 功能 的 Spout 对 象 ， 
不 过 可 能 由 于 其 还 处 于 试验 阶段 ， 用 到 的 地 方 并 不 多 。 

O 第 7~24 行 根据 输入 的 Bolt 和 Spout 对 象 构建 stormTopology 对 象 。 从 第 13 行 以 及 第 18 行 可 以 

看 出 ， 在 StormTopology 中 Spout 和 Bolts 均 为 对 象 序列 化 过 后 得 到 的 字 节 数组 。 

O 第 26~51 行 定义 setBolt 方 法 及 其 各 种 重 载 方法 。 从 第 50 行 代码 可 以 看 到 ，setBolt 方 法 会 
利用 BasicBoltExecutor 包 装 输入 的 IBasicBolt 对 象 ,其 中 BasicBoltExecutor 还 实现 了 消息 
的 跟踪 及 发 送 。 第 39 行 会 检测 输入 的 组 件 D 当 前 是 否 是 唯一 的 。 第 40~41 行 用 于 生成 
ComponentCommon 对 象 。 第 42 行 返回 一 个 BoltGetter 对 象 ， 根 据 上 节 的 分 析 ， 将 利用 其 为 
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Bolt 对 象 添加 输入 。 
a 第 72~77 行 定义 了 setSpout 方 法 ， 它 类 似 于 setBolt 方 法 ， 也 将 产生 ComponentCommon 对 象 。 
口 第 91~98 行 定义 了 getComponentCommon 方 法 ， 该 方法 主要 定义 输出 的 流 。 
口 第 100~107 行 定义 了 initCommon 方 法 ， 它 主要 对 ComponentCommon 对 象 进行 初始 化 ， 例 如 设 
置 并 行 度 和 标准 配置 等 。 


3.10.2 ConfigGetter 


ConfigGetter 是 定义 在 TopologyBuilder.java 中 的 一 个 类 ， 它 实现 了 ComponentConfiguration 
Declarer 接 口 ， 并 旦 继承 自 BaseConfigurationDeclarer 类 。 其 定义 如 下 所 示 : 


protected class ConfigGetter<T extends ComponentConfigurationDeclarer> extends BaseConfiguration 
Declarer<T> { 


String id; 
public ConfigGetter(String id) { 
id - id; 
) 
@Override 
邮 public T addConfigurations(Map conf) { 
if(conf!=null 8& conf.containsKey(Config.TOPOLOGY KRYO REGISTER)) { 
电 throw new IllegalArgumentException("Cannot set serializations for a component using fluent 
API"); 
) 
String currConf = commons.get( id).get json conf(); 
 commons.get( id).set json conf(mergeIntoJson(parseJson(currConf), conf)); 
return (T) this; 
) 


} 

其 中 _id 代 表 组 件 的 唯一 标识 符 。 在 通常 的 非 事务 流 处 理 中 ,不 能 设 定 组 件 的 序列 化 方法 ， 
4 能 采用 系统 默认 的 序列 化 方法 。ConfigGetter 会 根据 新 设置 的 配置 项 覆盖 组 件 默 认 的 配置 项 。 
具体 的 实现 过 程 中 ， 最 终 的 配置 项 会 被 序列 化 为 JSON 格 式 。 


并 


3.10.3 SpoutGetterjdlüBoltGetter 


SpoutGetter 基 本 上 实现 了 与 ConfigGetter 相 同 的 功能 ,唯一 的 区 别 是 Spout 不 需要 对 输入 进行 
声明 ， 其 定义 如 下 : 
protected class SpoutGetter extends ConfigGetter«SpoutDeclarer» implements SpoutDeclarer { 
public SpoutGetter(String id) ( 
super(id); 


} 
BoltGetter 不 但 继承 ConfigGetter 类 实现 了 对 于 Bolt 组 件 的 配置 定制 ， 同 时 还 实现 了 接口 
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BoltDeclarer。 由 于 其 方法 较 多 且 极 为 类 似 , 这 里 仅 以 fieldsGrouping 为 例 进行 分 析 。BoltGetter 


类 的 代码 如 下 : 
1 protected class BoltGetter extends ConfigGetter<BoltDeclarer> implements BoltDeclarer { 
2 private String boltId; 
3 
4 public BoltGetter(String boltId) { 
5 super(boltId); 
6 _boltId = boltId; 
7 } 
8 
9 public BoltDeclarer fieldsGrouping(String componentId, Fields fields) { 
10 return fieldsGrouping(componentId, Utils.DEFAULT STREAM ID, fields); 
11 } 
12 
13 public BoltDeclarer fieldsGrouping(String componentId, String streamId, Fields fields) { 
14 return grouping(componentId, streamId, Grouping. fields(fields.toList())); 
15 } 
16 private BoltDeclarer grouping(String componentId, String streamId, Grouping grouping) { 
17 _commons.get(_boltId).put_to_inputs(new GlobalStreamId(componentId, streamId), 
grouping); 
18 return this; 
19 } 
20 
23 @Override 
22 public BoltDeclarer grouping(GlobalStreamId id, Grouping grouping) { 
23 return grouping(id.get_componentId(), id.get_streamId(), grouping); 
24 } 
25 ] 


O 第 2 行 定 义 了 _bolt1d 变 量 ， 用 于 保存 Bolt 组 件 的 唯一 标识 符 。 
a 第 4~7 行 为 构造 函数 。 调 用 configGetter 的 构造 函数 ， 可 以 实现 配置 项 的 定制 功能 。 
口 第 9~15 行 定义 了 fieldsGrouping 及 其 重 载 方 法 ， 其 参数 包括 componentId、streamId 以 及 


fields ( 用 来 分 组 的 字段 名 列表 )。 如 果 没 有 指定 streamId， 默 认 将 使 用 default 作 为 
streamId, 

O 第 16~19 行 是 InputDeclarer 接 口 最 主要 的 实现 方法 。 它 的 输入 含义 为 : 按照 grouping 参 数 
定义 的 分 组 方式 ， 把 参数 componentId 指 定 的 组 件 中 以 参数 streamId 定 义 的 流放 在 本 组 件 
的 输入 定义 中 。 第 18 行 代码 返回 this 指 针 , 这 样 可 以 通过 函数 级 联 的 方式 为 本 组 件 添加 更 
多 的 输入 。 

a 第 22~24 行 是 一 个 重要 的 重 载 ， 其 输入 为 GlobalStreamId 以 及 分 组 方式 。 


3.10.4 


一 个 简单 例子 


这 里 举 一 个 简单 的 例子 ， 示 例 代码 如 下 : 


1 TopologyBuilder builder = new TopologyBuilder(); 


2 


builder.setSpout("spout1", new Spout1(), 1); 
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3 builder.setSpout("spout2", new Spout2(), 2); 
4 builder.setBolt("bolt, new Bolti(), 1) 
5 . shuffleGrouping("spout1") ; 

6 .fieldsGrouping("spout2", new Fields( “F” )); 


口 第 1 行 代 码 定义 了 TopologyBuilder 对 象 ， 这 个 对 象 已 在 3.1 
口 第 2~3 行 代码 设置 了 两 个 Spout。 


将 为 该 Bolt 添 加 两 个 输入 ， 一 个 以 shuffleGrouping 的 方 
fieldsGrouping 的 方式 连 到 spout2。 


3.41 异常 处 理 


0.1 节 介绍 。 


a 第 4 行 代码 设置 了 一 个 Bolt，setBolt 方 法 将 返回 一 个 BoltDeclarer 对 象 。 接着 第 5~6 行 代码 


式 连 到 spout1， 另 外 一 个 则 以 


在 Storm 中 ， 所 有 的 FailedException 都 是 被 捕获 的 ， 它 用 以 表示 消息 处 理 失败 。 在 捕获 该 异 


常 之 后 ，Storm 将 对 消息 进行 Fail 操 作 , 并 通过 Ack 系 统 将 消息 处 到 
后 Spout 端 会 根据 用 户 定义 的 逻辑 重 传 或 者 忽略 消息 等 。 


失败 的 情况 反映 到 Spout 端 ， 然 


用 户 代码 可 以 通过 抛 出 FailedException 来 通知 Storm 对 失败 的 消息 进行 处 理 ， 这 可 能 会 导致 


消息 重 传 。 若是 由 于 用 户 代 码 的 缺陷 导致 消息 处 理 失 败 ， 则 不 应 抛 出 该 异常 ,因为 即便 重 传 也 无 
济 于 解决 问题 。 更 好 的 处 理 方式 是 : 或 者 尽快 结束 Topology 的 运行 以 解决 问题 ， 或 者 干脆 直接 忽 


略 掉 该 消息 。FailedException 类 的 定义 如 下 所 示 : 


public class FailedException extends RuntimeException { 
public FailedException() { 
super(); 


} 


public FailedException(String msg) { 
super (msg) ; 


public FailedException(String msg, Throwable cause) { 
super(msg, cause); 


public FailedException(Throwable cause) { 
super (cause) ; 


} 


可 以 看 到 ，FailedException 继 承 自 RuntimeException 。 根 据 Java 的 语言 规范 ， 继 承 自 


RuntimeException 的 异常 类 不 需要 放置 于 使 用 类 的 函数 声明 中 。 


基础 函数 和 工具 类 


本 章 将 介绍 Storm 源 代码 中 那些 通用 且 关 键 的 基础 函数 和 工具 类 , 很 多 Storm 组 件 的 实现 都 依 
赖 于 它们 。 读 者 可 以 进行 简单 的 阅读 来 了 解 其 大 概 ,也 可 以 先 跳 过 这 一 章 ,， 待 用 到 这 里 的 函数 或 
工具 类 时 再 回来 查阅 。 


4.1 计时 器 
Storm 使 用 计时 器 线程 来 处 理 一 些 周 期 性 调度 事件 。 与 计时 器 相关 的 操作 主要 包括 创建 计时 
器 线程 、 查 看 线程 是 和 否 活 跃 、 向 线程 中 加 入 新 的 待 调度 事件 ， 以 及 取消 计时 器 线程 等 ， 下 面 简要 


介绍 这 些 操作 。 


4.1.1 mk-timer 

mk-timer 函 数 用 于 创建 一 个 计时 器 线程 。 其 基本 思想 为 : 首先 定义 一 个 优先 级 队列 ， 队 列 中 
的 元 素 类 型 为 < 目标 执行 时 间 ， 执行 函数 ,序列 号 >, 然后 在 当前 时 间 大 于 队列 中 的 目标 执行 时 间 
时 ， 取 出 队列 中 的 元 素 并 调用 其 执行 函数 。mk-timer 的 代码 如 下 : 


1 (defnk mk-timer [:kill-fn (fn [& _] )] 

2 (let [queue (PriorityQueue. 10 

3 (reify Comparator 

4 (compare [this 01 02] 

5 (- (first 01) (first 02)) 
6 ) 

7 (equals [this obj] 

8 true 

9 ))) 

10 active (atom true) 

11 lock (Object. ) 

12 notifier (Semaphore. 0) 

13 timer-thread (Thread. 

14 (fn [] 

15 (while @active 

16 (try 

17 (let [[time-secs _ _ :as elem] (locking lock (.peek queue))] 


18 (if (and elem (>= (current-time-secs) time-secs)) 
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a 

的 
a 
a 
及 
第 
a 


;; imperative to not run the function inside the timer lock 

;; otherwise, it's possible to deadlock if function deals with 
other locks 

33 (like the submit lock) 

(let [afn (locking lock (second (.poll queue)))] 

(afn)) 


(Time/sleep 1000) 


)) 
(catch Throwable t 


33 because the interrupted exception can be wrapped in a runtimeexception 
(when-not (exception-cause? InterruptedException t) 

(kill-fn t) 

(reset! active false) 

(throw t)) 


(.release notifier) ))] 
(.setDaemon timer-thread true) 
(.setPriority timer-thread Thread/MAX PRIORITY) 
(.start timer-thread) 
{:timer-thread timer-thread 
:queue queue 
:active active 
:lock lock 
:cancel-notifier notifier})) 


2~9 行 定义 函数 变量 queue 为 优先 级 队列 PriorityQueue， 其 初始 化 大 小 为 10; 同时 传人 
个 比较 妖 Comparator， 并 按照 元 素 的 第 一 部 分 ( 即 目 标 执行 时 间 ) 进行 比较 ,将 队列 中 
元 素 按 照 执 行 时 间 由 小 到 大 排列 。 

10 行 的 active 变 量 用 于 表明 该 定时 器 是 否 处 于 活跃 状态 。 

11 行 的 lock 为 0bject 对 象 ， 用 来 为 队列 对 象 的 操作 加 锁 。 这 是 由 于 向 队列 中 插入 元 素 以 
处 理 队 列 中 元 素 这 两 项 操作 是 在 不 同 的 线程 里 执行 的 。 

12 行 的 notifier 为 信号 量 。 计 时 器 线程 在 结束 时 , 会 调用 该 信号 量 的 release 方 法 释放 。 
13~33 行 定义 计时 器 线程 。 线 程 的 执行 函数 为 一 个 while 循 环 体 。 

第 17 行 调用 队列 的 peek 函 数 获得 队列 的 一 个 元 素 。:as 操 作 将 元 素 的 所 有 项 放 入 变量 
elem 中 ， 即 elem 的 内 容 为 < 目标 执行 时 间 ， 执 行 函数 ， 元 素 序 号 >。 

在 第 18 行 中 ， 若 elem 不 为 nul1， 并 且 当 前 时 间 大 于 或 等 于 元 素 的 执行 时 间 time-secs , 
则 调用 pol1 方 法 获取 该 元 素 ， 并 调用 second 方 法 获得 元 素 的 第 二 列 ， 即 待 执行 函数 afn， 
然后 调用 待 执行 函数 afn。 若 elem 不 为 nul1， 线 程 则 睡眠 1 秒 。 

第 26~32 行 对 异常 进行 处 理 。 若 不 为 InterruptedException 异 常 ， 则 调用 kil1-fn， 设 置 
active 为 false， 并 最 终 抛 出 异常 。kill-fn 为 构建 定时 器 时 传人 的 参数 ， 用 于 对 异常 情 
况 进行 处 理 , 该 函数 的 参数 为 抛 出 的 异常 。 例 如 , 在 Worker 的 mk-halting-timer 函 数 中 ， 
kill-fn 会 记录 异常 ， 然 后 结束 进程 。 该 函数 的 代码 如 下 : 


(defn mk-halting-timer [] 
(mk-timer :kill-fn (fn [t] 
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(log-error t "Error when processing event") 
(halt-process! 20 "Error when processing an event") 


)) 
m 在 第 33 行 中 ， 当 线程 的 循环 结束 后 ， 调 用 notifier 的 release 方 法 。 
口 第 34~36 行 将 线程 设置 为 后 台 线 程 并 赋予 其 最 高 优先 级 ， 然 后 启动 线程 。 
O 第 37~41 行 设置 返回 值 。 这 里 返回 的 是 一 个 哈 硕 表 ， 它 包含 了 定义 的 计时 器 线程 、 优 先 级 
队列 、 活 跃 状 态 和 锁 对象 等 信息 。 返 回 后 ， 外 部 环境 便 可 以 使 用 这 些 信息 。 


4.1.2 check-active! 


check-active! 也 数 用 于 检测 定时 器 的 active 变 量 ,， 若 定时 右 处 于 非 活 跃 状 态 ， 则 抛 出 异常 ， 
其 代码 如 下 : 


(defn- check-active! [timer] 
(when-not @(:active timer) 
(throw (IllegalStateException. "Timer is not active")))) 


4.1.3 schedule 


schedule 函 数 用 于 将 一 个 事件 注册 到 定时 器 中 ， 其 参数 包括 定时 器 timer 、 延 迟 执行 的 时 间 
delay-secs、 事 件 的 执行 函数 afn， 以 及 确定 是 否 检测 定时 器 活跃 的 参数 check-active ( 其 默认 值 
为 true )。 该 函数 的 代码 如 下 : 


1 (defnk schedule [timer delay-secs afn :check-active true] 

2 (when check-active (check-active! timer)) 

3 (let [id (uuid) 

4 ^PriorityQueue queue (:queue timer)] 

5 (locking (:lock timer) 

6 (.add queue [(* (current-time-secs) delay-secs) afn id]) 
7 


)) 


第 3 行 调用 uuid 函 数 产生 一 个 随机 数 来 代表 该 事件 的 事件 号 。 第 4~6 行 获取 定时 器 的 队列 对 
象 ， 并 向 其 中 添加 元 素 。 事 件 的 目标 执行 时 间 为 当前 时 间 加 上 delay-secs。 


4.1.4  schedule-recurring 


schedule 函 数 只 执行 一 次 注册 函数 ， 而 schedule-recurring 则 可 以 按照 设 定 的 时 间 反 复 执行 ， 
其 基本 思路 为 执行 完 当 前 函数 后 调用 函数 schedule 再 次 注册 自身 。 其 代码 如 下 : 


(defn schedule-recurring [timer delay-secs recur-secs afn] 
(schedule timer 
delay-secs 
(fn this [] 
(afn) 
(schedule timer recur-secs this :check-active false)) ; this avoids a race condition with 
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cancel-timer 


)) 


delay-secs 为 第 一 次 的 延迟 执行 时 间 ， 而 recur-secs 则 为 事件 循环 执行 的 间隔 时 间 。 重 新 注 
册 函 数 时 将 不 会 对 定时 器 的 活跃 状态 进行 检查 。 和 否则 ， 同 时 调用 cancel-timer 和 schedule 函 数 可 
能 会 有 竞争 ， 而 先 调用 cancel-timer 然 后 调用 schedule 方 法 ， 则 check-active 函 数 又 会 抛 出 异常 ， 
这 都 是 不 希望 看 到 的 。 


4.1.5 cancel-timer 


cancel-timer 函 数 用 于 结束 一 个 定时 吉 ， 它 会 调用 定时 器 notifier 的 acquire 操 作 ， 等 待定 时 4 
器 正常 结束 。 其 代码 如 下 : 


(defn cancel-timer [timer] 
(check-active! timer) 
(locking (:lock timer) 
(reset! (:active timer) false) 
(.interrupt (:timer-thread timer))) 
(.acquire (:cancel-notifier timer))) 


4.2 async-loop 


async-looprPÁ ZI Storm — ^E? ERR PK, WorkerflExecutor F TT e 2X Ee AB 
过 该 函数 来 启动 的 。 该 函数 使 用 一 个 线程 来 循环 调用 传人 的 函数 afn， 同 时 要 求 被 调用 的 afn 在 执 
行 结束 后 返回 一 个 时 间 间 隔 , 并 将 其 作为 与 下 次 调用 之 间 需 等 待 的 时 间 间 隔 。 该 聘 数 的 代码 如 下 : 


1 (defnk async-loop [afn 

2 :daemon false 

3 :kill-fn (fn [error] (halt-process! 1 "Async loop died!")) 
4 :priority Thread/NORM PRIORITY 

5 :factory? false 

6 :start true] 

7 (let [thread (Thread. 

8 


(fn [] 
9 (try-cause 
10 (let [afn (if factory? (afn) afn)] 
11 (loop [] 
12 (let [sleep-time (afn)] 
13 (when-not (nil? sleep-time) 
14 (sleep-secs sleep-time) 
15 (recur) ) 
16 
17 (catch InterruptedException e 
18 (log-message "Async loop interrupted!") 
19 
20 (catch Throwable t 


21 (log-error t "Async loop died!") 
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22 (kill-fn t) 
23 )) 

24 

25 (.setDaemon thread daemon) 


26 (.setPriority thread priority) 

27 (when start 

28 (.start thread)) 

29 33 should return object that supports stop, interrupt, join, and waiting? 
30 (reify SmartThread 


31 (start [this] 

32 (.start thread) ) 

33 (join [this] 

34 (.join thread)) 

35 (interrupt [this] 

36 (.interrupt thread) ) 

37 (sleeping? [this] 

38 (Time/isThreadWaiting thread) 
39 )) 

40 )) 


a 第 7~24 行 定义 了 一 个 线程 来 执行 前 面 计算 的 afn 函 数 。 在 第 10 行 中 ， 若 factory? 为 true， 
则 代表 输入 的 函数 afn 为 一 个 工厂 方法 ,此 时 需要 调用 afn 函 数 来 产生 目标 调用 函数 并 赋值 
给 afn。 例 如 ，Executor 中 的 mk-threads 方 法 在 调用 async-loop 时 传人 的 即 为 工厂 函数 ， 该 


函数 被 执行 后 将 返回 Executor 的 消息 循环 函数 。 
m 第 12~16 行 调用 afn 函 数 。afn 函 数 返回 一 个 等 待 时 间 ， 若 该 时 间 为 nul1， 则 循环 结 


m 第 17~22 行 对 异常 情况 进行 处 。 若 为 InterruptedException， 则 只 是 打印 消息 并 退出 循 


环 体 ， 其 他 情况 下 则 调用 kil1-fn 函 数 〈 它 是 在 调用 async-loop 函 数 时 被 传人 的 )。 
O 第 25~28 行 设置 参数 并 启动 线程 。 
a 第 30~39 行 实例 化 SmartThread 对 和 象 ， 用 于 对 async-1loop 中 的 线程 对 象 进行 操作 。 


4.3 event-manager 


event-manager 函 数 会 创建 一 个 单独 的 线程 来 处 理事 件 ， 创 建 时 可 以 指定 该 线程 是 否 是 一 个 后 
RATE, 处理 过 程 中 发 生 的 任何 错误 都 会 导致 该 线程 退出 。 该 函数 创建 了 一 个 LinkedBlockingOoueue 
用 来 存储 要 执行 的 事件 ， 同 时 还 定义 了 3 个 变量 added、processed 和 running。added 用 来 记录 当前 
总 共有 多 少 要 执行 的 事件 ，processed 记 录 了 当前 已 经 处 理 了 多 少 事件 ，running 则 用 于 标识 该 线 


程 是 否 活跃 。 

event-manager 哨 数 的 处 理 逻 辑 很 简单 ,就 是 一 直 不 断 地 尝试 从 LinkedBlockingQueue 中 获取 
件 ， 获 取 到 了 就 处 理 并 更 新 processed 的 值 ， 如 果 没 有 新 事件 ， 该 获取 方法 会 被 阻塞 直到 有 新 日 
事件 加 入 到 队列 中 。 目 前 ， 该 函数 主要 用 在 Supervisor 中 ， 其 定义 如 下 : 


1 (defprotocol EventManager 
2 (add [this event-fn]) 
3 (waiting? [this]) 
4 (shutdown [this])) 


E 


H- 


B 


4.4 even-sampler 03 


5 

6 (defn event-manager 

7 "Creates a thread to respond to events. Any error will cause process to halt" 
8 [daemon?] 

9 (let [added (atom 0) 

10 processed (atom 0) 

11 ^LinkedBlockingOueue queue (LinkedBlockingQueue. ) 

12 running (atom true) 

13 runner (Thread. 

14 (fn [] 

15 (try-cause 

16 (while @running 

17 (let [r (.take queue)] 

18 (x) 

19 (swap! processed inc))) 

20 (catch InterruptedException t 

21 (log-message "Event manager interrupted")) 
22 (catch Throwable t 

23 (log-error t "Error when processing event") 
24 (halt-process! 20 "Error when processing an event")) 
25 2] 

26 (.setDaemon runner daemon?) 

27 (.start runner) 

28 (reify 

29 EventManager 

30 (add [this event-fn] 

31 33 should keep track of total added and processed to know if this is finished yet 
32 (when-not @running 

33 (throw (RuntimeException. "Cannot add events to a shutdown event manager") )) 
34 (swap! added inc) 

35 (.put queue event-fn) 

36 

37 (waiting? [this] 

38 (or (Time/isThreadWaiting runner) 

39 (= @processed @added) 

40 )) 

41 (shutdown [this] 

42 (reset! running false) 

43 (.interrupt runner) 

44 (.join runner) 

45 ) 

46 ))) 


调用 event-manager 方 法 后 ,将 返回 一 个 实现 了 EventManager 协 议 的 对 象 。 通过 该 对 象 ， 用 户 
可 以 向 新 创建 的 处 理 线程 的 LinkedBlockingQueue 中 添加 事件 ， 也 可 以 关闭 该 处 理 线程 。 


4.4 even-sampler 


在 Storm 中 , 我 们 采用 采样 的 方式 更 新 运行 统计 , Storm UI 上 显示 的 数据 都 是 根据 采样 率 进行 
估算 的 值 。 
even-sampler 定 义 了 一 个 均匀 采样 器 ， 输 入 参数 freq 代 表 了 采样 频率 。iz 为 Java Random 类 型 的 


64 第 4 章 基础 函数 和 工具 类 
变量 , 代表 一 个 随机 数 生成 器 。 它 每 次 随机 生成 一 个 介 于 [0, freq ) 之 间 的 值 , 并 将 该 值 保存 在 target 
变量 中 。 每 次 调用 该 函数 时 ， 都 会 将 当前 值 与 target 进 行 比较 ， 若 相等 则 返回 true。 但 要 注意 的 
是 , 只 有 当 i 大 于 等 于 freq 时 才 重 新 置 为 0, 这 保证 了 采样 的 均匀 性 。even-sampler 困 数 的 定义 如 下 : 
1 (defn even-sampler [freq] 
2 (let [freq (int freq) 
3 start (int O) 
4 r (java.util.Random.) 
5 curr (MutableInt. -1) 
6 target (MutableInt. (.nextInt r freq))] 
7 (with-meta 
8 (fn [] 
9 (let [i (.increment curr)] 
10 (when (»- i freq) 
11 (.set curr start) 
12 (.set target (.nextInt r freq)))) 
13 (= (.get curr) (.get target))) 
14 {:rate freq}))) 


Kžtmk-stats-sampler HJ 


(defn mk-stats-sampler [conf] 
(even-sampler (sampling-rate conf))) 


F 生 成 一 个 even-sampler: 


函数 sampleing-rate 的 值 由 TOPOLOGY-STATS-SAMPLE-RATE 配 置 指定 : 


(defn sampling-rate [conf] 
(-»» (conf TOPOLOGY-STATS-SAMPLE-RATE) 
(/ 1) 
int)) 


参数 TOPOLOGY-STATS-SAMPLE-RATE 在 Storm 中 的 默认 值 为 0.05， 此 时 sampling-rate 函 数 的 返回 值 应 


为 20， 即 每 隔 20 条 消息 采样 一 条 消息 。 


4.5 ZooKeeper 工具 类 


Storm 对 ZooKeeper 的 访问 是 基于 CuratorFramewor 


4.5.1 mk-client 


Kk 的， 本 节 将 介绍 如 何 访问 ZooKeeper。 


mk-client 函 数 用 于 创建 一 个 ZooKeeper 连 接 ， 并 注册 CuratorListener 方 法 来 监听 ZooKeeper 


的 事件 〈 例 如 节点 的 创建 、 删 除 等 )， 一旦 有 这 样 的 


听 器 default-watcher 只 负责 打印 相关 消息 。 该 函数 的 
1 (defnk mk-client [conf servers port :root "" 

2 
auth-conf)))] 


EH FALE,. ， 该 监听 需 就 会 被 调用 。 默 认 的 监 
定义 如 下 : 


:watcher default-watcher :auth-conf nil] 
(let [fk (Utils/newCurator conf servers port root (when auth-conf (ZookeeperAuthInfo. 
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3 (.. fk 

4 (getCuratorListenable) 

5 (addListener 

6 (reify CuratorListener 

7 (‘void eventReceived [this ^CuratorFramework fk ^CuratortEvent e] 

8 (when (= (.getType e) CuratorEventType/WATCHED) 

9 (let [^WatchedEvent event (.getWatchedEvent e)] 

10 (watcher (zk-keeper-states (.getState event)) 

11 (zk-event-types (.getType event)) 

12 (.getPath event)))))))) 

a 第 2 行 通过 Utils 的 newCurator 方 法 来 创建 一 个 Curator 对 象 ， 该 对 象 可 用 于 对 ZooKeeper 进 
行 数据 操作 。 

O 第 5 行为 该 Curator 添 加 了 一 个 事件 监 昕 器， 当 ZooKeeper 的 状态 发 生变 化 时 ,watcher 函 数 
将 会 被 调用 。 


4.5.2 create-node 


tt 


create-node 子 数 会 利用 CuratorFramework 对 象 zk 来 创建 
存在 三 种 类 型 的 节点 ， 具 体 如 下 所 示 。 
C) EPHEMERAL: 临时 节点 ， 连 接 断 开 后 节点 即 被 删除 。 
口 PERSISTENT: 永久 节点 ， 连 接 断 开 后 节点 会 继续 保持 。 
口 PERSISTENT SEQUENTIAL: 顺序 永久 节点 ， 节 点 名 字 上 带 有 序号 ， 且 ZooKeeper 会 保证 该 类 
节点 是 按照 序号 递增 的 方式 被 创建 的 。 


节点 并 设置 数据 。 在 ZooKeeper 中 ， 


相关 代码 如 下 : 

1 (def zk-create-modes 

2 {:ephemeral CreateMode/EPHEMERAL 

3 :persistent CreateMode/PERSISTENT 

4 :sequential CreateMode/PERSISTENT SEQUENTIAL}) 

5 

6 (defn create-node 

7 ([^CuratorFramework zk ^String path ^bytes data mode] 

8 (.. zk (create) (withMode (zk-create-modes mode)) (withACL ZooDefs$Ids/OPEN ACL 


_UNSAFE) (forPath (normalize-path path) data))) 
9 ([^CuratorFramework zk ^String path ^bytes data] 
10 (create-node zk path data :persistent))) 


4.5.3 get-data 


该 函数 利用 CuratorFramework 的 getData 方 法 获取 数据 。 值得 注意 的 是 , 该 函数 可 以 传人 watch? 
参数 ， 以 指明 是 否 对 路 径 path 进 行 监听 。 当 数据 更 新 时 ， 注 册 的 watcher 回 调 方法 会 被 调用 。 回 
调 方法 被 调用 后 就 失效 ， 如 果 想 继续 监听 ， 需 要 在 下 次 调用 get-data 函 数 时 进行 重新 设置 。 该 函 
数 的 代码 如 下 : 
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(defn get-data [^C 


uratorFramework zk ^String path watch?] 


(let [path (normalize-path path)] 


(try-cause 
(if (exi 


sts-node? zk path watch?) 


(if watch? 


(.. zk (getData) (watched) (forPath path)) 
(.. zk (getData) (forPath path)))) 


(catch KeeperException$NoNodeException e 


;; this is 


nil )))) 


fine b/c we still have a watch from the successful exists call 


T 


活跃 时 ，Worker 可 以 机 


通过 watcher 的 回调 , 系统 可 以 尽快 地 得 到 数据 的 变化 通知 。 例如 ， 当 Topology 的 状态 变动 非 


恨 据 该 变化 来 调整 自身 执行 的 Executor。 但 是 ，watcher 的 回调 方法 不 能 保证 


一 定 会 被 调用 到 ， 通 常 需要 与 定时 顺 结 合 使 用 。 


4.5.4 ”进程 内 启动 ZooKeeper 


mk-inprocess-zookeeper 函 数 用 于 在 一 个 进程 内 打开 ZooKeeper 服 务 ， 主 要 用 于 LocalCluster 
模式 。 其 基本 思路 为 利用 NIOServerCnxnFactory 来 管理 ZooKeeper 连 接 。 该 工厂 方法 需要 绑 定 到 一 
个 端口 号 ，Storm 从 2000 开 始 探测 可 以 使 用 的 端口 号 ,并 最 终 由 mk-inprocess-zookeeper 函 数 返回 
ZooKeeper 启 动 所 使 用 的 端口 号 。 该 函数 的 代码 如 下 : 


1 (defnk mk-inproc 
2 (let [localf 
3 zk (ZooK 
4 [retport 
5 
6 
7 
8 
9 [retport 
10 (recur ( 


11 (log-message 
12 (.startup fa 


ess-zookeeper [localdir :port nil] 
ile (File. localdir) 
eeperServer. localfile localfile 2000) 
factory] (loop [retport (if port port 2000)] 
(if-let [factory-tmp (try-cause (NIOServerCnxnFactory/create 
Factory retport 60) ;; 60 is the default maxclientcnxns 
(catch BindException e 
(when (» (inc retport) (if port port 65535)) 
(throw (RuntimeException. "No port is available to launch an 
inprocess zookeeper.")))))] 
factory-tmp] 
inc retport))))] 
"Starting inprocess zookeeper at port " retport " and dir " localdir) 
ctory zk) 


13 [retport factory] 


14 » 


4.6 LocalStat 


e 


LocalState 定 义 了 一 个 轻 量 级 的 、 可 持久 化 的 K/V 数 据 库 。 它 的 效率 不 高 ， 每 次 读 写 都 要 进 
行 磁盘 操作 ， 所 以 一 般 只 能 用 于 读 写 次 数 不 多 的 场景 。 在 Storm 中 ，Localstate 主 要 在 Supervisor 
和 Worker 中 使 用 。 它 的 实现 如 下 : 


1 public class Loc 
2 private Versi 
3 


alState { 
onedStore vs; 
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4 public LocalState(String backingDir) throws IOException { 

5 . VS = new VersionedStore(backingDir); 

6 } 

7 

8 public synchronized Map«Object, Object» snapshot() throws IOException { 

9 String latestPath = _vs.mostRecentVersionPath() ; 

10 if(latestPath==null) return new HashMap«Object, Object>(); 

11 return (Map«Object, Object») Utils.deserialize(FileUtils.readFileToByteArray(new File 
(latestPath))); 

12 } 

13 

14 public Object get(Object key) throws IOException { 

15 return snapshot().get(key); 

16 } 

17 

18 public synchronized void put(Object key, Object val) throws IOException { 

19 Map<Object, Object» curr = snapshot(); 

20 curr.put(key, val); 

21 persist(curr); 

22 } 

23 

24 public synchronized void remove(Object key) throws IOException { 

25 Map<Object, Object> curr = snapshot(); 

26 curr.remove(key) ; 

27 persist(curr); 

28 } 

29 

30 private void persist(Map«Object, Object» val) throws IOException { 

31 byte[] toWrite - Utils.serialize(val); 

32 String newPath = vs.createVersion(); 

33 FileUtils.writeByteArrayToFile(new File(newPath), toWrite); 

34 |. Vs. succeedVersion(newPath); 

35 . vs.cleanup(4); 

36 } 

37} 


这 个 类 使 用 了 VersionedStore 对 象 ， 该 对 象 主要 实现 一 个 简单 的 带 版 本 的 文件 管理 器 。 它 能 


够 生成 新 的 版 本 号 ( 基于 系统 当前 时 间 )， 
以 .version 为 后 级 的 文件 作为 其 版 本 信息 ， 
涉及 的 方法 。 


路 径 。 


同时 给 每 个 成 功 写 入 的 本 地 文件 添加 一 个 对 应 的 


还 能 够 管理 版 本 的 保存 和 删除 。 下 面 简要 介绍 该 类 中 


O LocalState 构 造 函 数 需 要 指定 一 个 root 路 径 , 同时 会 将 这 个 路 径 作 为 VersionedSstore 的 root 


口 snapshot 方 法 获取 当前 root 路 径 下 最 新 版 本 文件 中 记录 的 信息 的 快照 ， 它 不 会 修改 文件 内 容 。 
口 get 方 法 获取 最 新 版 本 文件 中 所 包含 的 由 键 指定 的 内 容 。 


改过 后 的 内 容 。 
O remove 方法 将 当前 最 新 版 本 的 内 容 中 
存 更 改过 后 的 内 容 。 


O put 方 法 将 新 的 键 值 对 放 入 当前 最 新 版 本 的 内 容 中 ， 同 时 创建 一 个 最 新 版 本 的 文件 保存 更 


由 键 指定 的 值 删除 , 同时 创建 一 个 最 新 版 本 的 文件 保 


68 第 4 章 基础 函数 和 工具 类 


O persist 方 法 是 真正 实现 保存 更 改 后 内 容 的 方法 。 它 将 内 容 序 列 化 ， 通 过 VersionedSstore 
创建 一 个 新 版 本 的 文件 , 将 序列 化 后 的 内 容 保存 到 该 文件 中 , 然后 调用 succeedversion 方 
法 为 该 文件 创建 版 本 信息 ， 并 调用 cleanup 方 法 清除 老 版 本 的 文件 ， 保 证 只 留 下 最 新 的 4 
个 版 本 的 文件 。 


4.7 ClusterState 


ClusterState 协 议定 义 了 一 系列 用 于 对 ZooKeeper 进 行 操作 的 方法 。mk-distributed-cluster- 
state 隙 数 则 返回 一 个 实现 了 该 协议 的 对 象 , 该 对 象 的 基本 方法 都 是 利用 Zookeeper.clj 中 定义 的 方 
法 实现 的 ， 这 里 主要 讨论 回调 函数 的 注册 和 调用 ， 相 关 代 码 如 下 : 


1 (defn mk-distributed-cluster-state [conf] 
2 (let [zk (zk/mk-client conf (conf STORM-ZOOKEEPER-SERVERS) (conf STORM-ZOOKEEPER-PORT) : 
auth-conf conf)] 


3 (zk/mkdirs zk (conf STORM-ZOOKEEPER-ROOT)) 

4 (.close zk)) 

5 (let [callbacks (atom {}) 

6 active (atom true) 

7 zk (zk/mk-client conf 

8 (conf STORM-ZOOKEEPER-SERVERS) 

9 (conf STORM-ZOOKEEPER-PORT) 

10 :auth-conf conf 

11 :root (conf STORM-ZOOKEEPER-ROOT) 

12 :watcher (fn [state type path] 

13 (when active 

14 (when-not (= :connected state) 

15 (log-warn "Received event " state ":" type ":" path " with 
disconnectedZookeeper.")) 

16 (when-not (= :none type) 

17 (doseq [callback (vals @callbacks) ] 

18 (callback type path)))) 

19 2] 

20 (xeify 

21 ClusterState 

22 (register [this callback] 

23 (let [id (uuid)] 

24 (swap! callbacks assoc id callback) 

25 id 

26 

27 (unregister [this id] 

28 (swap! callbacks dissoc id)) 

29 )) 


a 第 2~4 行 根据 配置 项 中 定义 的 ZooKeeper 服 务 器 、 端 口号 和 认证 方式 ， 调 用 mk-client 方 法 
创建 一 个 新 的 ZooKeeper 客 户 端 ， 并 在 第 3 行 创建 根 目录 。 

a 第 5 行 定义 了 用 来 存储 所 有 回调 函数 的 callbacks 变 量 
口 第 7~19 行 重新 创建 ZooKeeper 的 客户 端 ,不 过 这 次 是 将 第 11 行 传人 的 :root 作 为 该 客户 端的 
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根 目 录 ， 该 客户 端的 其 他 操作 都 是 相对 于 该 根 目 录 进 行 的 。 预 先 创建 根 目 录 有 助 于 提高 
ZooKeeper 的 访问 性 能 。 
a 第 12~19 行 定义 调用 mk-client 时 传人 的 回调 函数 , 其 中 第 17~18 行 将 依次 调用 callbacks 中 
存储 的 函数 。 
a 第 22~26 行 调用 register 方 法 来 更 新 callbacks 变 量 。 于 是 ， 新 注册 的 方法 便 可 以 被 
ZooKeeper 的 watcher 方 法 回调 。 
a 第 27~28 行 取消 了 一 个 回调 的 注册 。 
通过 对 callbacks 变 量 进 行 操作 ， 就 可 实现 动态 地 增 减 回调 函数 这 一 目标 。 


4.8 StormClusterState ag 


StormClusterState 协 议定 义 了 与 Storm 相 关 的 ZooKeeper 操 作 ， 例 如 读 取 Topology 的 任务 分 
配 、 向 ZooKeeper 中 发 送 心 跳 信息 等 。 

mk-storm-cluster-state 函 数 用 于 创建 一 个 实现 了 StormClusterState 协 议 的 对 象 。 本 节 主 要 
讨论 其 中 有 关 ZooKeeper 使 用 的 内 容 。 该 函数 的 代码 如 下 : 


1 (defn mk-storm-cluster-state [cluster-state-spec] 

2 (let [[solo? cluster-state] (if (satisfies? ClusterState cluster-state-spec) 
3 [false cluster-state-spec] 

4 [true (mk-distributed-cluster-state cluster-state-spec)]) 

5 assignment-info-callback (atom {}) 

6 supervisors-callback (atom nil) 

7 assignments-callback (atom nil) 

8 storm-base-callback (atom {}) 


9 state-id (register 

10 cluster-state 

11 (fn [type path] 

12 (let [[subtree & args] (tokenize-path path)] 

13 (condp = subtree 

14 ASSIGNMENTS-ROOT (if (empty? args) 

15 (issue-callback! assignments-callback) 

16 (issue-map-callback! assignment-info-callback (first args))) 

17 SUPERVISORS-ROOT (issue-callback! supervisors-callback) 

18 STORMS-ROOT (issue-map-callback! storm-base-callback (first args)) 

19 33 this should never happen 

20 (halt-process! 30 "Unknown callback for subtree " subtree args) 

21 ) 

22 

23 (doseq [p [ASSIGNMENTS-SUBTREE STORMS-SUBTREE SUPERVISORS-SUBTREE WORKERBEATS-SUBTREE 
ERRORS -SUBTREE] ] 

24 (mkdirs cluster-state p)) 


O 第 2 行 根据 传人 参数 是 否 实 现 了 Clusterstate 协 议 ， 来 判断 是 否 应 该 调用 mk-distributed- 
cluster-state 来 创建 ClusterState 对 象 以 操作 ZooKeeper。 若 传人 的 cluster-state-spec 
未 实现 ClusterState 协 议 ， 则 说 明 该 ClusterState 对 象 仅 供 其 自己 使 用 ， 退 出 时 需要 断 开 
与 ZooKeeper 的 连接 。 
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a 第 5~8 行 分 别 定义 了 一 些 回调 函数 的 集合 ， 用 于 监听 不 同 的 目录 。 

口 第 9~21 行 调用 ClusterState 的 Teigster 方 法 将 一 个 回调 函数 注册 到 ClusterState 的 
callbacks 变 量 中 。 第 12~21 行 定义 了 该 回调 函数 ， 它 是 根据 watcher 回 调 函 数 发 回 的 路 径 
来 调用 相应 的 函数 。 例 如 ， 若 发 回 的 路 径 为 SUPERVISORS-ROOT， 则 调用 supervisors- 
callback 所 对 应 的 回调 方法 。issue-callback! 函 数 在 执行 完 supervisors-callback 方 法 后 
会 将 回调 函数 重 置 为 null。 

例如 ， 对 于 assignments 方 法 的 实现 : 


(assignments [this callback] 
(when callback 
(reset! assignments-callback callback)) 
(get-children cluster-state ASSIGNMENTS-SUBTREE (not-nil? callback))) 

若 callback 函 数 不 为 nul1, 首先 将 assignments-callback 重 置 为 传人 的 callback 函 数 , 然后 在 
调用 get-children 函 数 时 将 最 后 一 个 参数 设 为 true， 表 示 客 户 端 需要 监测 该 路 径 下 数据 的 变化 ， 
一 旦 路 径 ASSIGNMENTS-SUBTREE 下 的 数据 发 生变 化 ，ZooKeeper 将 通知 客户 端 来 执行 回调 函数 。 

这 样 做 是 很 有 意义 的 ， 当 Nimbus 重 新 分 配 任 务 时 , 各 个 Supervisor 需 要 在 第 一 时 间 获 得 通知 ， 
并 根据 重新 分 配 的 任务 来 调整 自身 运行 。 

由 于 ZooKeeper 中 回调 方法 的 调用 是 不 被 保证 的 ， 通常 还 需要 额外 的 线程 来 定期 获取 数据 ， 
以 实现 数据 同步 。 


通信 和 机制 


在 进程 之 间 ，Storm 采 用 ZMQ 进 行 通信 。ZMQ 是 一 个 开源 的 、 跨 语言 的 网 络 通信 库 ， 它 非常 
简洁 ， 运 行 性 能 高 ， 使 用 起 来 也 十 分 灵活 。 读 者 可 以 参考 以 下 链接 来 学 习 ZMQ: 
口 http:/zguide.zeromq.org/ 
O http://zguide.zeromq.org/page:all#Core-Messaging-Patterns 
对 于 同一 进程 内 部 的 诸多 线程 ,Storm 则 采用 Disruptor Queue 来 完成 它们 之 间 的 通信 。 通过 阅 
读 下 面 的 链接 ， 你 将 对 LAMX Disruptor 的 特点 和 原理 产生 更 加 深刻 的 认识 。 
O http://Imax-exchange. github.io/disruptor/ 
O http://ifeve.com/disruptor/ 
O http://www.cnblogs.com/fxjwind/p/3 180073.html 
O http://blog.sina.com.cn/s/blog 68ffc7a4010150yl.html 
在 本 章 中 ， 我 们 主要 介绍 Storm 中 进程 间 以 及 进程 内 线程 之 间 的 通信 方法 。 


5.1 进程 间 通 信 


对 于 不 同 的 系统 模式 ， 进 程 之 间 通 信 的 具体 实现 方式 也 是 不 同 的 。 

在 分 布 式 模式 下 ， 如 前 所 述 ，Storm 将 采用 ZMQ 进 行 通信 。 

而 在 LocalCluster 模 式 下 ,如 果 参 数 storm.1local.mode.zmq 的 值 为 false ( 默认 为 false ), Storm 
将 会 采用 线程 模拟 进程 的 方式 启动 服务 , 即 通过 一 个 LinkedBlockingQueue 来 模拟 进程 间 通 信 。 如 
果 参 数 storm.local.mode.zmq 的 值 为 true， 则 如 同 分 布 式 模式 一 样 ， 使 用 ZMQ 来 进行 通信 。 

Storm 首 先 定义 了 一 些 必要 的 通信 协议 ， 以 便 更 加 灵活 地 支持 以 上 这 两 种 模式 。 而 具体 的 通 
信 过 程 ， 则 是 对 协议 的 进一步 实现 和 使 用 。 


5.1.1 ”进程 则 通信 协议 


用 于 进程 间 通 信 的 协议 主要 包括 Connection 和 Context。 
Connection 协 议定 义 了 3 个 方法 ， 用 于 接收 和 发 送 消 息 : 


(defprotocol Connection 
(recv-with-flags [conn flags]) 
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(send [conn task message]) 
(close [conn]) 


recv-with-flags 方 法 用 来 接收 消息 ， 参 数 flags 表 示 是 否 为 阻塞 方式 。send 方 法 send 用 来 向 
某 一 个 Task 发 送 消 息 ，close 方 法 用 于 关闭 一 个 连接 。 
Context 协 议定 义 了 创建 和 关闭 Socket 连 接 的 方法 : 


(defprotocol Context 
(bind [context storm-id port]) 
(connect [context storm-id host port]) 
(term [context]) 
) 


在 上 述 代 码 中 ，bind 方 法 用 于 绑 定 到 一 个 端口 号 并 返回 一 个 Socket 对 象 ， 该 Socket 对 象 主要 
负责 接收 消息 ， 而 connect 方 法 则 用 于 连接 到 一 个 端口 号 并 返回 该 端口 号 ， 主 要 负责 发 送 消息 。 
term 方 法 用 来 关闭 连接 。 


5.1.2 ”LocalCluster 模 式 实现 


在 LocalCluster 模 式 下 , 系统 默认 ( storm.local.mode.zmq 为 false ) 采 用 一 个 进程 来 模拟 Storm 
集群 环境 ，Nimbus 、Supervisor 、Worker 等 都 是 该 进程 中 的 一 个 线程 。 所 以 ， 这 种 情况 下 的 通信 
实际 上 是 进程 内 通信 。Storm 使 用 LinkedBlockingQueue 来 模拟 消息 的 发 送 和 接收 。 接 下 来 ， 我 们 
介绍 LocalCluster 模 式 下 Storm 是 如 何 实现 Connection 及 Context 协 议 的 。 

1. LocalConnection 

LocalConnection 类 型 实现 了 协议 Connection, 它 的 成 员 变 量 包括 storm-id、 port, queues-map、 
lock 以 及 queue， 其 中 queues-map 为 一 个 哈 希 表 ， 键 由 storm-id 以 及 端口 号 port 连 接 而 成 ， 值 为 一 
个 LinkedBlockingQueue 队 列 。 成 员 变 量 queue 为 接收 队列 。LocalConnection 的 代码 如 下 : 


1 (deftype LocalConnection [storm-id port queues-map lock queue] 

2 Connection 

3 (recv-with-flags [this flags] 

4 (when-not queue 

5 (throw (IllegalArgumentException. "Cannot receive on this socket"))) 
6 (if (= flags 1) 

7 (.poll queue) 

8 (.take queue))) 


9 (send [this task message] 

10 (let [send-queue (add-queue! queues-map lock storm-id port)] 
11 (.put send-queue [task message]) 

12 )) 

13 (close [this] 

14 


O 第 3~8 行 实现 recv-with-flags 函 数 , 该 函数 的 第 一 个 参数 为 this 指 针 , 即 协议 中 的 conn 参 数 为 
LocalConnection 类 型 。flags 为 1 表示 以 非 阻塞 方式 获取 消息 ， 否 则 会 以 阻塞 方式 获取 消息 。 
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口 第 9~12 行 实现 send 孙 数 。 第 10 行 通过 add-queue! 孙 数 获得 一 个 发 送 消 息 的 队列 。 第 11 行 向 
队列 里 发 送 一 条 消息 ， 该 消息 由 两 部 分 构成 ， 即 TaskId 以 及 消息 的 实际 内 容 。 
add-queue! 的 实现 如 下 : 


(defn add-queue! [queues-map lock storm-id port] 
(let [id (str storm-id "-" port)] 
(locking lock 
(when-not (contains? @queues-map id) 
(swap! queues-map assoc id (LinkedBlockingQueue. )))) 
(@queues-map id))) 


queues-map 的 键 由 storm-id 与 port 连 接 而 成 , 该 函数 首先 根据 传人 的 storm-id 以 及 port 计 算得 
到 queues-map 的 键 并 将 其 存储 到 变量 id 中 。 若 queues-map 里 没有 id， 函 数 就 创建 一 个 新 的 
LinkedBlockingQueue 对 象 将 其 与 id 关 联 。 函 数 的 末尾 返回 id 所 对 应 的 队列 ,该 队列 或 者 是 新 创建 
的 或 者 是 已 经 存在 的 。 

2. LocalContext 

LocalContext 类 型 中 含有 域 queues-map 以 及 用 于 操作 queues-map 的 锁 对 象 lock。 该 类 
Context 协 议 ， 其 代码 如 下 : 


ves 


实现 了 


(deftype LocalContext [queues-map lock] 
Context 
(bind [this storm-id port] 
(LocalConnection. storm-id port queues-map lock (add-queue! queues-map lock storm-id port))) 
(connect [this storm-id host port] 
(LocalConnection. storm-id port queues-map lock nil) 


(e [this] 
) 

在 上 述 代码 中 ，bind 函 数 主 要 用 于 接收 消息 ， 它 会 根据 输入 的 storm-id 和 port 创 建 一 个 
LocalConnection 对 象 ， 并 传人 一 个 LinkedBlockingQueue 队 列 作为 接收 队列 。connect 方 法 则 主要 
用 于 发 送 消息 ， 它 同样 会 创建 LocalConnection 对 象 ， 只 不 过 其 接收 队列 为 nil。 

要 创建 一 个 LocalContext 对 象 ， 需 使 用 mk-local-context 函 数 。 这 里 ，queues-map 被 初始 化 为 
atom 哈 希 类 型 ， 而 lock 锁 对 象 则 是 一 个 新 创建 的 0bject 对 象 : 


(defn mk-local-context [] 
(LocalContext. (atom {}) (Object.))) 


5.1.3 分布 式 模式 实现 
在 分 布 式 模式 下 ，Storm 采 用 ZMQ 来 进行 进程 间 通 信 。 接 下 来 ， 我 们 介绍 一 下 分 布 式 模式 下 
Storm 是 如 何 实现 通信 协议 的 。 


1. ZMOConnection 
ZMOConnection 类 实现 了 Connection 协 议 ， 其 代码 如 下 : 
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(deftype ZMQConnection [socket ^ByteBuffer bb] 
Connection 
(recv-with-flags [this flags] 
(let [parti (mq/recv socket flags)] 
(when parti 
(when-not (mg/recv-more? socket) 
(throw (RuntimeException. "Should always receive two-part ZMQ messages"))) 
(parse-packet parti (mq/recv socket))))) 
(send [this task message] 
(.clear bb) 
(.putShort bb (short task)) 
(mq/send socket (.array bb) NOBLOCK-SNDMORE) 
(mq/send socket message ZMQ/NOBLOCK)) ;; TODO: how to do backpressure if doing noblock?... need 
to only unblock if the target disappears 
(close [this] 
(.close socket) 
)) 
(defn mk-connection [socket] 
(ZMQConnection. socket (ByteBuffer/allocate 2))) 


成 员 变 量 socket 表 示 ZMQ 的 连接 字符 串 。bb 为 预先 分 配 的 ByteBuffer 空 间 ， 用 来 存储 已 被 序 
列 化 的 端口 号 。 

ZMQ 会 分 两 次 发 送 消 息 : 第 一 次 发 送 TaskId, 第 二 次 则 为 具体 的 消息 内 容 。 接 收 时 同样 先 接 
收 TaskId， 然 后 接收 具体 内 容 。 

mk-connection 痕 数 用 来 实例 化 一 个 ZMQConnection 对 象 。 

2. ZMOContext 

ZoMContext 类 实现 了 Context 协 议 ， 其 代码 如 下 : 


(deftype ZMQContext [context linger-ms hwm local?] 
Context 
(bind [this storm-id port] 
(-» context 
(mq/socket mq/pull) 
(mq/set-hwm hwm) 
(mq/bind (get-bind-zmq-url local? port)) 
mk- connection 
)) 
(connect [this storm-id host port] 
(-» context 
(mq/socket mq/push) 
(mq/set-hwm hwm) 
(mg/set-linger linger-ms) 
(mq/connect (get-connect-zmq-url local? host port)) 
mk-connection)) 
(term [this] 
(.term context)) 
ZMQContextQuery 
(zmq-context [this] 
context) ) 
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O context 为 ZMOContext 对 象 。 

口 linger-ms 表 示 调 用 ZMQ Socket 的 关闭 方法 term 后 未 发 送 消息 的 等 待 时 间 。 若 超出 该 时 间 ， 

未 发 送 的 消息 将 被 丢弃 。 该 变量 的 默认 值 为 5 秒 ， 由 zmq.1linger.millis 配 置 参数 设置 。 

口 hwm 表 示 ZMQ 发 送 队 列 的 高 水 平 线 。 若 发 送 队 列 里 面 的 消息 个 数 超过 hwm， 新 来 的 消息 可 

能 会 被 丢弃 。 该 变量 的 默认 值 为 0， 即 没有 限制 。 

O local? 表 示 系 统 是 否 运 行 在 单机 环境 下 ， 它 被 用 于 LocalCluster 模 式 的 ZMQ 中 ， 即 将 

storm.local.mode.zmqix E jtrue. 

O bind 方 法 设置 了 ZMQ 的 Socket 参 数 。 注 意 这 里 Socket 模 式 设置 为 pull 类 型 ， 表 示 返 回 的 
Socket 主 要 用 于 接收 消息 。Bind 方 法 会 调用 get-bind-zmq-ur1 函 数 来 获得 Socket 连 接 字符 

串 ， 如 下 面 的 代码 所 示 ， 协 议 的 主机 名 部 分 为 *， 表 示 从 当前 主机 对 应 的 端口 接收 消息 : 


(defn get-bind-zmq-url [local? port] 
(if local? 
(str "ipc://" port ".ipc") 
(str "tcp://*:" port))) 
类 似 地 ，connect 方 法 也 会 设置 ZMQ 的 Socket 参 数 ， 只 不 过 它 将 Socket 模 式 设置 为 push。 该 函 
数 返 回 的 Socket 主 要 用 于 发 送 消息 © o 
connect 方 法 会 调用 get-connect-zmq-ur1 函 数 以 获得 Socket 连 接 字符 串 。 从 下 面 的 代码 可 以 看 
出 , get-connect-zmq-url 需 要 给 定 主机 和 端口 号 , 表示 将 消息 发 送 到 目标 主机 host 的 端口 号 port 上 : 


(defn get-connect-zmq-url [local? host port] 
(if local? 
(str "ipc://" port ".ipc") 
(str "tcp://" host ":" port))) 


5.1.4. 协议 使 用 


Storm 会 调用 launch-receive-thzread1! 函 数 来 启动 Worker 所 对 应 的 消息 接收 线程 。 该 函数 在 后 
台 启 动 接收 线程 ， 同 时 返回 一 个 用 于 终止 线程 接收 的 函数 。 其 代码 如 下 : 


1 (defnk launch-receive-thread! 

2 [context storm-id port transfer-local-fn max-buffer-size 
3 :daemon true 

4 :kill-fn (fn [t] (System/exit 1)) 

5 :priority Thread/NORM PRIORITY] 

6 (let [max-buffer-size (int max-buffer-size) 

7 vthread (async-loop 

8 


(fn [] 
9 (let [socket (msg/bind context storm-id port)] 
10 (fn [] 
11 (let [batched (ArrayList.) 
12 init (msg/recv socket) ] 
13 (loop [[task msg :as packet] init] 


14 (if (= task -1) 
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15 (do (log-message "Receiving-thread:[" storm-id ", " port "] 
received shutdown notice") 
16 (.close socket) 
17 nil ) 
18 (do 
19 (when packet (.add batched packet)) 
20 (if (and packet (« (.size batched) max-buffer-size)) 
21 (recur (msg/recv-with-flags socket 1)) 
22 (do (transfer-local-fn batched) 
23 o ))))))))) 
24 :factory? true 
25 :daemon daemon 
26 :kill-fn kill-fn 
27 :priority priority)] 
28 (fn [] 
29 (let [kill-socket (msg/connect context storm-id "localhost" port)] 
30 (log-message "Shutting down receiving-thread: [" storm-id ", " port "]") 
31 (msg/send kill-socket 
32 -1 
33 (byte-array [])) 
34 (log-message "Waiting for receiving-thread:[" storm-id ", " port "] to die") 
35 (.join vthread) 
36 (.close kill-socket) 
37 (log-message "Shutdown receiving-thread: [" storm-id ", " port "]") 
38 )))) 


a 在 第 2 行 的 接收 参数 中 , context 为 上 下 文 对 象 , 它 可 以 是 LocalContext 对 象 或 者 ZMOContext 
对 和 象 。transfer-local-fn 对 应 Worker 的 一 个 接收 函数 ， 用 来 处 理 从 队列 中 接收 到 的 消息 ， 
即将 消息 分 发 到 Worker 的 各 个 Disruptor Queue 中 ,max-buffer-size 表 示 最 少 收 到 多 少 消息 
之 后 调用 transfer-local-fn 哨 数 , 它 由 topology.receiver.buffer.size 配 置 项 确定 , 默认 
值 为 8。 

O 第 7 ~ 38 行 通过 调用 async-1loop 方 法 启动 了 一 个 接收 线程 。 第 9 行 调用 协议 的 bind 方 法 返回 
一 个 Socket 对 象 。 对 于 不 同 的 Context 对 象 ， 返 回 的 Socket 是 不 同 的 。 目 前 ，Storm 发 送 与 
接收 消息 的 协议 如 下 。 

口 普通 消息 由 两 部 分 构成 , 第 一 个 部 分 表示 消息 的 来 源 TaskId, 第 二 个 部 分 为 消息 的 具体 

内 容 。 

O 接收 端 Task 以 阻塞 方式 接收 第 一 条 消息 , 然后 换 由 非 阻塞 方式 接收 其 他 消息 , 直到 缓存 的 

消息 数目 超过 max-buffer-size 的 值 ; 

a 若 收 到 消息 的 TaskId 为 -1 ， 表 示 收 到 关闭 接收 线程 的 信号 。 第 16 行 关闭 Socket， 第 17 行 返 

回 nil1， 表 示 退 出 线程 的 循环 体 。 

口 第 11 行 初始 化 batched 变 量 ， 用 于 存储 接收 到 的 消息 。 

a 第 12 行 以 阻塞 模式 调用 msg/recv 函 数 。 

a 第 19% 行 中 ,， 若 消息 不 为 nul1， 则 将 消息 存储 到 batched 缓 存 中 。 

a 第 20~23 行 , 若 收 到 的 消息 不 为 空 ， 同 时 缓存 的 消息 数目 少 于 max-buffer-size， 则 继续 以 
非 阻 塞 模式 接收 消息 。 和 否则 ， 调 用 transfer-local-fn 函 数 处 理 目 前 缓存 的 消息 ， 同 时 返 
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回 0 表 示 终 止 第 13 行 定义 的 循环 。 接 下 来 ，async-loop 中 的 循环 会 重新 调用 第 10 行 定义 的 
函数 ， 开 始 新 一 轮 的 消息 接收 。 
a 第 28~38 行 定义 了 一 个 用 来 杀 掉 接 收 线程 的 函数 。 它 首先 向 线程 发 送 一 条 消息 ,消息 对 应 
的 TaskId 为 -1， 然 后 调用 线程 的 join 方法 以 及 Socket 的 close 方 法 ， 最 终 杀 掉 线程 。 
Worker 中 的 launch-receive-thread 方 法 用 来 调用 上 面 的 范 数 ， 其 代码 如 下 : 


(defn launch-receive-thread [worker] 
(log-message "Launching receive-thread for 
(msg-loader/launch-receive-thread! 

(:mq-context worker) 

(:storm-id worker) 

(:port worker) 

(:transfer-local-fn worker) 

(-» worker :storm-conf (get TOPOLOGY-RECEIVER-BUFFER-SIZE)) 
:kill-fn (fn [t] (halt-process! 11)))) 


" (:assignment-id worker) ":" (:port worker)) 


5.2 进程 内 通 音信 


Disruptor Queue 是 用 于 线程 之 间 通 信 的 高 效 通信 队列 。 为 了 提高 性 能 ,， Storm 中 所 有 的 进 


通信 都 会 基于 Disruptor Queue 来 实现 。 下 面 我 们 就 来 介绍 Storm 使 用 Disruptor Queue 的 细节 。 


Ini 
ot 


5.2.1 Disruptor Queue 的 使 用 


在 Storm 中 ， 我 们 使 用 Disruptor Queue 类 来 对 Disruptor Queue 的 使 用 进行 封装 ， 本 节 简 要 介 
绍 一 下 该 类 。 


1. 成 员 变量 分 析 
DisruptorQueue 类 对 LAMX Disruptor 框 架 进 行 了 封装 ，Storm 使 用 这 个 类 来 发 送 和 接收 消息 。 


该 类 的 定义 如 下 : 


public class DisruptorQueue { 
static final Object FLUSH CACHE = new Object(); 
static final Object INTERRUPT - new Object(); 


RingBuffer«MutableObject» buffer; 
Sequence consumer; 
SequenceBarrier barrier; 


// TODO: consider having a threadlocal cache of this variable to speed up reads? 


volatile boolean consumerStartedFlag - false; 
ConcurrentLinkedQueue<Object> cache = new ConcurrentLinkedQueue() ; 


} 
口 _cache 为 一 个 ConcurrentLinkedQueue 对 象 。 知 队列 还 未 启动 用 户 就 已 经 发 送 来 了 消息 , 那 


么 这 些 消息 就 会 被 临时 存放 在 该 变量 中 。 
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口 FLUSH_CATCH 为 特殊 类 型 的 对 象 。 系 统 会 在 队列 启动 时 间 队 列 中 插入 该 对 象 ， 而 收 到 该 对 

象 后 ， 对 _cache 中 的 缓存 数据 进行 处 理 。 

O _INTERRUPT 为 男 外 一 个 信号 对 象 ， 收 到 该 对 象 时 消息 的 接收 循环 将 被 结 

口 _buffer 为 RingBuffer 对 象 ， 对 应 于 Disruptor 队 列 的 存储 。 

口 _consumeit 为 Sequence 对 象 ， 对 应 于 Disruptor 队 列 的 接收 端 。 

口 barrier 为 SequenceBarrier 对 象 ， 用 于 等 待 并 获取 可 读数 据 。 

口 consumerStartedF1ag 用 来 表示 接收 端 是 否 开 始 ， 当 接收 端 尚 未 开始 时 ， 会 将 数据 放 于 成 
n cache., 

2. publish? ZK 

publish 函 数 用 于 向 RingBuffer 对 象 buffer 中 存储 数据 ， 其 代码 如 下 所 示 : 


1 public void publish(Object obj, boolean block) throws InsufficientCapacityException { 
2 

3 if(consumerStartedFlag) ( 

4 final long id; 

5 if(block) ( 

6 id = buffer.next(); 

7 ) else ( 

8 id = buffer.tryNext(1); 

9 

10 final MutableObject m = buffer.get(id); 
11 m. setObject(obj); 

12  buffer.publish(id); 

13 ) else { 

14 . cache. add(obj) ; 

15 if(consumerStartedFlag) flushCache(); 

16 } 

17 } 

18 public void publish(Object obj) { 

19 try { 

20 publish(obj, true); 

21 } catch (InsufficientCapacityException ex) { 
22 throw new RuntimeException("This code should be unreachable!"); 
23 } 

24 ] 


若 接收 端 已 经 启动 , 则 调用 RingBuffer 对 象 的 next 或 者 tryNext 方 法 来 获取 下 一 个 存储 位 置 的 
id。 然 后 ， 代 码 的 第 10~12 行 会 设置 并 调用 RingBuffer 对 象 的 publish 函 数 ， 将 要 发 送 的 消息 对 象 
存储 到 RingBuffer 中 。 目 前 ，Storm 都 采用 阻塞 的 方法 发 布 消息 ， 即 block 参 数 为 true。 否 则 block 
Zl false, 消息 将 被 存 人 _cache 对 象 中 ,然后 判断 是 否 应 调用 flushCache 操 作 , 该 操作 会 向 队 
列 中 发 布 一 个 FLUSH_CACHE 对 象 。 

3. consumeBatchToCursorey Zit 

consumeBatchToCursor 国 数 会 访问 RingBuffer 对 象 并 获取 一 组 可 读 的 数据 , 它 通常 被 放 在 一 个 
循环 中 反复 执行 以 获取 数据 , 用 来 处 理 RingBuffer 中 存储 的 数据 , 其 参数 cursor 为 目前 RingBuffer 
的 最 大 可 读 游标 ，handler 为 EventHandler 对 象 ， 是 对 收 到 消息 的 回调 函数 。 例 如 ， 由 Worker 的 函 
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数 mk-transfer-tuples-handler 创 建 的 一 个 新 函数 通过 不 断 调用 consumeBatchToCursor 方 法 来 获 
得 发 送 至 该 Worker 的 数据 。consumeBatchToCursor 的 代码 如 下 : 


1 private void consumeBatchToCursor(long cursor, EventHandler«Object» handler) { 
2 for(long curr = _consumer.get() + 1; curr <= cursor; curre) { 
3 try { 

4 MutableObject mo = _buffer.get(curr) ; 

5 Object o = mo.o; 

6 mo. setObject (nu11); 

7 if(o--FLUSH CACHE) { 

8 Object c = null; 

9 while(true) { 

10 c = cache.poll(); 

11 if(c==null) break; 

12 else handler.onEvent(c, curr, true); 

13 } 

14 ) else if(o--INTERRUPT) { 

15 throw new InterruptedException("Disruptor processing interrupted"); 
16 ) else { 

17 handler.onEvent(o, curr, curr -- cursor); 

18 } 

19 } catch (Exception e) { 

20 throw new RuntimeException(e); 

21 } 

22 

23 //TODO: only set this if the consumer cursor has changed? 

24 _consumer.set (cursor) ; 

25 } 


OQ fE*R21T P, _consumer.get() r1 I ARF EMILE Eo ~consumeBatchToCursor pai 

回 一 组 数据 ， 这 组 数据 的 区 间 为 [_ consumer.get()*-1, cursor]. 

口 第 4~6 行 获取 相应 的 消息 对 象 。 

口 第 7~13 行 处 理 接收 端 尚未 启动 时 发 送 的 消息 , 这 些 消息 被 放 入 _cache 变 量 中 。 当 接收 端 启 

动 后 ， 将 优先 发 送 缓存 _cache 中 的 消息 。 

a 第 17 行 调用 handler 的 onEvent 函 数 。 若 curr 与 cursor 相 同 ， 则 表示 该 Batch 结 束 ，Worker 

会 根据 Batch 是 否 结束 来 决定 是 否 将 缓存 的 消息 发 送出 去 。 

O 第 24 行 重新 设置 consumer 所 对 应 的 游标 。 
consumeBatchwWhenAvailable 函 数 会 等 待 _ barrier 的 函数 返回 ， 并 调用 consumeBatchToCursor 

函数 来 处 理 消息 ， 相 关 代 码 如 下 : 


public void consumeBatchWhenAvailable(EventHandler«Object» handler) { 
try ( 
final long nextSequence = _consumer.get() + 1; 
final long availableSequence - barrier.waitFor(nextSequence, 10, TimeUnit.MILLISECONDS); 
if(availableSequence »- nextSequence) ( 
consumeBatchToCursor(availableSequence, handler); 


} catch (AlertException e) { 
throw new RuntimeException(e); 
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} catch (InterruptedException e) { 
throw new RuntimeException(e); 
} 


} 

这 里 要 注意 ， 目 前 waitFor 函 数 最 多 等 待 10 毫 秒 。 

consumeBatch 函 数 对 应 于 非 阻 塞 情 况 ， 它 通过 getCursor 的 返回 值 直接 调用 comsumeBatchTo 
Cursor 函 数 。consumeBatch 主 要 用 于 Spout 的 消息 处 理 线程 , 由 于 该 线程 中 还 要 执行 一 些 其 他 操作 ， 
因此 必须 进行 非 阻 塞 的 调用 。 其 代码 如 下 : 


public void consumeBatch(EventHandler«Object» handler) ( 
consumeBatchToCursor( barrier.getCursor(), handler); 
) 


5.2.2 DisruptorQueue 的 Clojure 处 理 器 


disruptor.clj 文 件 中 定义 了 一 些 封装 了 DisruptorQueue 方 法 的 方法 ， 这 里 主要 介绍 consumer- 
loop*PKZX Fllcol jure-handler rh XX 

consume-loop* PK 2 FH F Ja a — 4 ii 28 RE, ， 该 线程 会 不 断 调用 DisruptorQueue 的 
consume-batch-when-available 方 法 。 而 且 线 程 在 启动 后 ， 还 会 执行 consume- start! 操 作 ， 设 置 
DisruptorQueue 中 的 consumerStartedFlag 标 志 ， 以 表明 该 队列 可 以 接收 数据 了 : 


(defnk consume-loop* [^DisruptorQueue queue handler :kill-fn (fn [error] (halt-process! 1 "Async loop 
died!"))] 
(let [ret (async-loop 
(fn [] 
(consume-batch-when-available queue handler) 
0) 
:kill-fn kill-fn 


(consumer-started! queue) 
ret 


(defn consume-batch-when-available [^DisruptorQueue queue handler] 
(.consumeBatchWhenAvailable queue handler)) 


clojure-handler 函 数 用 来 实例 化 一 个 EventHandler 对 象 ， 其 输入 参数 为 一 个 函数 Cafn), H 
在 实现 onEvent 方 法 时 将 调用 这 个 传人 的 函数 。clojure-handler 的 代码 如 下 : 


(defn clojure-handler [afn] 
(xeify com.lmax.disruptor.EventHandler 
(onEvent [this o seq-id batchEnd?] 
(afn o seq-id batchEnd?) 


))) 


Worker 中 的 mk-transfer-tuples-handler 函 数 将 使 用 clojure-handler 来 定义 一 个 EventHandler， 
这 将 在 第 9 章 中 介绍 。 


第 6 章 
Nimbus 


Nimbus 可 以 说 是 Storm 中 最 核心 的 部 分 ， 它 的 主要 功能 有 两 个 ， 具 体 如 下 所 示 。 

口 对 Topology 的 任务 进行 分 配 调 度 。 

a 接收 用 户 的 命令 并 做 相应 的 处 理 ， 例 如 Topology 的 提交 (submit), Z&7E (kill), Boe 
(activate )、 暂 停 (deactivate ) 以 及 重新 调度 (rebalance )。 

Nimbus 本 身 里 基于 Thrift 杠 架 ( http://thrift.apache.org/ ) 实 现 的 , 它 使 用 了 Thrift 的 THsHaServer 
服务 。THsHaServer 即 半 同 步 半 异步 服务 模式 ， 它 使 用 一 个 单独 的 线程 来 处 理 网 络 WO， 使 用 一 个 
独立 的 工作 者 线程 池 来 处 理 消 息 ， 大 大 提高 了 消息 的 并 发 处 理 能 力 。 


6.1 Nimbus 服务 接口 定义 
Nimbus 服 务 接口 是 用 Thrift 的 语法 编写 的 ， 它 定义 了 Nimbus 提 供 的 所 有 服务 ， 其 代码 如 下 : 


1 service Nimbus { 


2 void submitTopology(1: string name, 2: string uploadedJarLocation, 3: string jsonConf, 4: 
StormTopology topology) throws (1: AlreadyAliveException e, 2: InvalidTopologyException 
ite); 

3 void submitTopologyWithOpts(1: string name, 2: string uploadedJarLocation, 3: string jsonConf, 


4: StormTopology topology, 5: SubmitOptions options) throws (1: AlreadyAliveException e, 2: 
InvalidTopologyException ite); 


4 void killTopology(1: string name) throws (1: NotAliveException e); 

5 void killTopologyWithOpts(1: string name, 2: KillOptions options) throws (1: NotAliveException e); 

6 void activate(1: string name) throws (1: NotAliveException e); 

7 void deactivate(1: string name) throws (1: NotAliveException e); 

8 void rebalance(1: string name, 2: RebalanceOptions options) throws (1: NotAliveException e, 2: 
InvalidTopologyException ite); 

9 


10 // need to add functions for asking about status of storms, what nodes they're running on, looking 
at task logs 


12 string beginFileUpload(); 
13 void uploadChunk(1: string location, 2: binary chunk); 
14 void finishFileUpload(1: string location); 


16 string beginFileDownload(1: string file); 
17 //can stop downloading chunks when receive O-length byte array back 
18 binary downloadChunk(1: string id); 
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19 

20 // returns json 

21 string getNimbusConf(); 

22 // stats functions 

23 ClusterSummary getClusterInfo(); 

24 TopologyInfo getTopologyInfo(1: string id) throws (1: NotAliveException e); 
25 //returns json 

26 string getTopologyConf(1: string id) throws (1: NotAliveException e); 

27 StormTopology getTopology(1: string id) throws (1: NotAliveException e); 

28 StormTopology getUserTopology(1: string id) throws (1: NotAliveException e); 


a 第 2~3 行 定义 了 提交 Topology 的 方法 。 

口 第 4~5$ 行 定义 了 杀 死 Topology 的 方法 。 

口 第 6 行 定义 了 激活 某 个 Topology 的 方法 。 

O 第 7 行 定 义 了 暂停 某 个 Topology 的 方法 。 

a 第 8 行 定 义 了 重新 调度 Topology 任 务 的 方法 。 

a 第 12~14 行 定义 了 上 传 文件 的 方法 。 

口 第 16~18 行 定义 了 下 载 文 件 的 方法 。 

口 第 21 行 定义 了 获取 Nimbus 服 务 所 使 用 的 Storm 配 置 项 的 方法 ， 它 返回 的 是 一 个 经 过 JSON 
序列 化 处 理 的 字符 串 。 

O 第 23 行 定义 了 获取 当前 集群 总 体 统计 信息 的 方法 。 

口 第 24 行 定义 了 获取 某 个 Topology 的 总 体 统计 信息 的 方法 。 

口 第 26 行 定义 了 获取 某 个 Topology 的 Storm 配 置 项 的 方法 。 

a 第 27 行 定义 了 获取 系统 Topology 的 方法 。 系 统 Topology 是 指 在 用 户 提 交 的 Topology 基 础 上 
添加 acker、metric 等 系统 定义 bolt 后 形成 的 Topology。 

O 第 28 行 定义 了 获取 用 户 提交 的 Topology 的 方法 。 

由 于 Storm 运 行 在 JVM 上 ， 前 面 定义 的 结构 需 使 用 Thrift 转 换 成 对 应 的 Java 代 码 。 在 得 到 
Nimbus.java 文 件 中 ， 接 口 Iface 的 定义 如 下 : 


1 public interface Iface { 

2 public void submitTopology(String name, String uploadedJarLocation, String jsonConf, Storm 
Topology topology) throws AlreadyAliveException, InvalidTopologyException, org.apache. 
thrift7.TException; 


public void submitTopologyWithOpts(String name, String uploadedJarLocation, String jsonConf, 
StormTopology topology, SubmitOptions options) throws AlreadyAliveException, Invalid 
Topology Exception, org.apache.thrift7.TException; 

5 

6 public void killTopology(String name) throws NotAliveException, org.apache.thrift7.TException; 

7 

8 


public void killTopologyWithOpts(String name, KillOptions options) throws NotAliveException, 
org.apache.thrift7.TException; 


10 public void activate(String name) throws NotAliveException, org.apache.thrift7.TException; 
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12 
13 
14 


15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 


31 
32 
33 
34 


35 
36 


37 


public void deactivate(String name) throws NotAliveException, org.apache.thrift7.TException; 


public void rebalance(String name, RebalanceOptions options) throws NotAliveException, 
InvalidTopologyException, org.apache.thrift7.TException; 


public String beginFileUpload() throws org.apache.thrift7.TException; 

public void uploadChunk(String location, ByteBuffer chunk) throws org.apache.thrift7.TException; 
public void finishFileUpload(String location) throws org.apache.thrift7.TException; 

public String beginFileDownload(String file) throws org.apache.thrift7.TException; 

public ByteBuffer downloadChunk(String id) throws org.apache.thrift7.TException; 

public String getNimbusConf() throws org.apache.thrift7.TException; 

public ClusterSummary getClusterInfo() throws org.apache.thrift7.TException; 


public TopologyInfo getTopologyInfo(String id) throws NotAliveException, org.apache.thrift7. 
TException; 


public String getTopologyConf(String id) throws NotAliveException, org.apache.thrift7.TException; 


public StormTopology getTopology(String id) throws NotAliveException, org.apache.thrift7. 
TException; 


public StormTopology getUserTopology(String id) throws NotAliveException, org.apache.thrift7. 
TException; 
} 


Nimbus 提 供 了 该 接口 的 具体 实现 ， 我 们 会 在 后 面 详细 地 介绍 这 些 方法 。 


6.2 Nimbus 相关 的 数据 结构 


Nimbus 中 用 到 的 数据 结构 主要 有 两 大 类 : Java 定 义 的 数据 结构 以 及 Clojure 定 义 的 数据 结构 。 
Java 定 义 的 数据 结构 主要 用 于 任务 分 配 ， 而 Clojure 定 义 的 数据 结构 则 主要 来 充当 一 些 Storm 的 元 


数据 。 
6.2.1 


Java 数据 结构 


图 6-1 给 出 了 Nimbus 中 用 到 的 几 个 Java 数 据 结 构 间 的 类 关系 图 。 
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图 6-1 _ Java 数据 结构 


下 面 简要 介绍 图 中 各 个 对 象 的 功能 。 

口 ExecutorDetails 对 象 记 录 了 每 个 Executor 所 对 应 的 startTask 和 endTask， 这 样 定 义 是 为 了 

保证 Storm 在 计算 Executor 时 ， 每 个 都 Executor 都 是 一 个 连续 的 任务 集合 。 

口 TopologyDetails 对 象 记 录 了 每 个 Topology 的 信息 ， 包 括 topologyId、Topology 使 用 过 的 配 

置 项 、Topology 对 象 本 身 、 每 个 Executor 到 所 属 组 件 的 以 及 numWorkers 等 信息 。 

口 Topologies 对 象 包含 了 一 组 Topology, 它 定义 了 一 个 <topology-id, TopologyDetails> 集 合 

以 及 一 个 ctopology-name，topology-id> 集 合 。 

口 SupervisorDetails 对 象 记录 了 当前 Supervisor 的 状态 , 包括 id、host、meta 和 allports 等 信息 。 

口 WorkerSlot 对 象 定义 了 一 个 可 用 资源 ， 它 包含 nodeId 和 port 两 个 成 员 变 量 ， 其 中 nodeId 就 

是 前 面 提 到 的 supervisorid， 它 实际 上 是 指 某 个 Supervisor 机 需 上 的 某 个 端口 号 。 

口 SchedulerAssignmentImp1 对 象 定义 了 当前 Topology 的 任务 分 配 情况 ， 它 包含 topologyId 以 

及 为 该 Topology 分 配 的 <ExecutorDetails,WorkerSlot> 映 射 关 系 。 

口 Cluster 对 象 定义 了 集群 当前 的 状态 信息 ， 包 括 所 有 Supervisor 信 息 以 及 当前 所 有 Topology 
的 分 配 信息 等 ， 它 是 任务 调度 器 进行 任务 分 配 、 调 度 的 基础 。 


6.2.2 ”Clojure 数 据 结构 


Nimbus 使 用 Clojure 语 言 定 义 了 一 些 共 享 数据 结构 以 及 Storm 元 数据 ， 其 中 最 主要 的 数据 结构 
是 nimbus-data,Storm 元 数据 包括 StormBase 、Assignment 和 SupervisorInfo。 
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1. nimbus-data 介 绍 


nimbus-data 数 据 结构 定义 了 很 多 公用 数据 ， 其 代码 如 下 所 示 : 


1 (defn nimbus-data [conf inimbus] 

2 (let [forced-scheduler (.getForcedScheduler inimbus) ] 

3 {:conf conf 

4 :inimbus inimbus 

5 :submitted-count (atom 0) 

6 :storm-cluster-state (cluster/mk-storm-cluster-state conf) 
7 :submit-lock (Object. ) 

8 :heartbeats-cache (atom {}) 


9 :downloaders (file-cache-map conf) 

10 :uploaders (file-cache-map conf) 

11 :uptime (uptime-computer) 

12 :validator (new-instance (conf NIMBUS-TOPOLOGY-VALIDATOR)) 
13 :timer (mk-timer :kill-fn (fn [t] 

14 (log-error t "Error when processing event") 

15 (halt-process! 20 "Error when processing an event") 
16 )) 

17 :scheduler (mk-scheduler conf inimbus) 

18 ») 


O 第 5 行 定义 了 当前 已 经 提交 的 Topology 的 数目 。 

口 第 6 行 定 义 了 cluster-state 对 象 ， 该 对 象 可 用 于 将 数据 存储 到 ZooKeeper 中 以 及 从 

ZooKeeper 读 取 数 据 。 

口 第 9 行 和 第 10 行 分 别 定义 了 downloaders 和 uploaders 缓 存 。 当 用 户 提交 Topology 的 时 候 , A 
统 会 创建 一 个 上 传 流 并 将 其 放 人 uploaders 绥 存 中 ; 而 当 Supervisor 从 Nimbus 下 载 Topology 
的 jar 包 时 ， 系 统 则 会 创建 一 个 下 载 流 并 将 其 放 入 downloaders 缓 存 中 。 任 何 一 种 操作 完成 
时 ， 其 所 对 应 的 上 传 或 下 载 流 就 会 被 关闭 ， 且 流 所 传递 的 内 容 也 会 被 从 缓存 中 移 除 。 

口 第 11 行 定义 了 当前 Nimbus 的 启动 时 间 。 

口 第 12 行 定义 了 一 个 validator ， 它 可 用 于 对 Topology 进 行 检 测验 证 。 目 前 使 用 的 是 

Defaultvalidator， 其 validate 操 作 实 际 上 什么 都 没 做 。 

a 第 13~16 行 定义 了 一 个 计时 器 ， 并 给 出 了 当 计 时 器 处 理 失 败 时 需要 调用 的 方法 。 

口 最 后 一 行 则 定义 了 Nimbus 所 使 用 的 调度 器 。 

2. StormBase 

StormBase 定 义 了 Topology 的 基本 信息 ， 其 代码 如 下 : 


(defrecord StormBase [storm-name launch-time-secs status num-workers component-»executors]) 


它 主要 包括 如 下 参数。 

口 storm-name: Topology 名 字 。 

口 launch-time-secs: 启动 时 间 。 

口 status: Topology 的 当前 状态 。 

口 num-workers: Topology 需 要 使 用 的 Worker 的 数目 。 
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口 component->executors: 保存 了 <component-id，parallelism> 信 息 。 
3. Assignment 


Assignment 定 义 了 当前 Topology 的 任务 分 配 情况 ， 其 代码 如 下 : 
(defrecord Assignment [master-code-dir node-»host executor->node+port executor-»start-time-secs]) 


它 主要 包括 如 下 参数 。 

口 master-code-dir : Nimbus 在 本 地 保存 该 Topology 信 息 的 路 径 ， 其 中 主要 含有 三 个 
文件 一 一 stormjarjar、stormcode.ser 以 及 stormconf ser。 

口 node->host: 定义 了 该 Topology 被 分 配 到 的 <supervisor-id，hostname> 集 合 。 

口 executor->node+port: 定义 了 该 Topology 中 Executor 的 分 配 情况 ，node 对 应 于 supervisor- 
id，port 则 是 Supervisor 的 一 个 端口 。 

口 executor->start-time-secs: 定义 了 该 Topology 对 应 的 Supervisor 的 启动 时 间 。 

4. SupervisorInfo 

SupervisorInfo 定 义 了 Supervisor 本 身 的 信息 ， 其 代码 如 下 : 


(defrecord SupervisorInfo [time-secs hostname assignment-id used-ports meta scheduler-meta uptime-secs]) 


它 主要 包含 如 下 参数 。 

口 time-secs: 最 近 一 次 更 新 SupervisorInfo 数 据 的 时 间 。 

口 hostname: Supervisor 所 在 机 器 的 主机 名 。 

口 assignment-id: 目前 等 同 于 supervisor-id。 

口 used-ports: 当前 已 被 使 用 的 端口 列表 。 

口 meta: Supervisor 的 元 数据 信息 ， 目 前 主要 用 来 记录 Supervisor 的 所 有 端口 列表 。 
口 scheduler-meta: Supervisor 的 调度 元 数据 信息 ， 目 前 没有 使 用 。 
口 uptime-secs: Supervisor 截 至 上 次 心跳 更 新 时 的 启动 时 间 。 


6.3 Nimbus 中 的 线程 介绍 


除 主 服务 线程 之 外 ，Nimbus 中 还 有 一 个 计时 器 线程 ， 它 的 主要 作用 有 3 个 ， 具 体 如 下 所 示 。 

O 调用 mk-assignment 方 法 启动 新 一 轮 的 任务 分 配 ， 调 用 do-cleanup 方 法 清理 Storm 元 数据 。 

这 两 项 操作 会 每 隔 NIMBUS-MONITOR-FREQ-SECS ( 默认 值 为 10 秒 ) 执行 一 次 。 

口 调用 clean-inbox 方 法 清理 Nimbus 本 地 目录 中 Topology 的 jar 包 。 该 操作 则 每 隔 NIMBUS- 

CLEANUP-INBOX-FREQ-SECS (默认 值 是 600 秒 ) 执行 一 次 。 

口 执行 Topology 的 状态 转移 事件 。 这 一 事件 则 只 有 当 Nimbus 接 收 到 对 应 的 服务 请 求 ( 如 kill、 
rebalance 、activate 和 deactivate ) 时 才 会 被 触发 。 

这 里 我 们 先 来 介绍 会 被 周期 性 调用 的 3 个 方法 : mk-assignments、do-cleanup 和 clean-inbox。 

而 状态 转移 事件 的 执行 过 程 ， 我 们 则 留 到 下 一 节 中 单独 讨论 。 
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6.3.1 mk-assignments 


mk-assignments 方 法 主要 负责 对 当前 集群 中 所 有 Topology 进 行 新 一 轮 的 任务 调度 。 它 一 方面 
会 检查 已 运行 的 Topology 所 占用 的 资源 ， 判 断 它 们 是 否 有 问题 ， 是 否 需 要 重新 分 配 ; 另 一 方面 也 
会 根据 系统 当前 的 可 用 资源 ， 为 新 提交 的 Topology 分 配 任务 。 然 后 ，mk-assignments 方 法 会 将 所 
有 的 分 配 信息 保存 或 更 新 到 ZooKeeper 中 ，Supervisor 会 周期 性 地 检查 这 些 分 配 信息 ， 并 根据 这 些 
分 配 信息 做 相应 的 调度 处 理 。 该 方法 的 代码 如 下 所 示 : 


1 (defnk mk-assignments [nimbus :scratch-topology-id nil] 

2 (let [conf (:conf nimbus) 

3 storm-cluster-state (:storm-cluster-state nimbus) 

4 ^INimbus inimbus (:inimbus nimbus) 

5 ;; read all the topologies 

6 topology-ids (.active-storms storm-cluster-state) 

7 topologies (into {} (for [tid topology-ids] 

8 {tid (read-topology-details nimbus tid)])) 
9 topologies (Topologies. topologies) 


10 ;; read all the assignments 

11 assigned-topology-ids (.assignments storm-cluster-state nil) 

12 existing-assignments (into {} (for [tid assigned-topology-ids] 

13 (when (or (nil? scratch-topology-id) (not= tid scratch-topology-id)) 

14 (tid (.assignment-info storm-cluster-state tid nil)]))) 

15 ;; make the new assignments for topologies 

16 topology->executor->nodet+port (compute-new-topology->executor->node+port 

17 nimbus 

18 existing-assignments 

19 topologies 

20 scratch-topology-id) 

21 

22 now-secs (current-time-secs) 

23 basic-supervisor-details-map (basic-supervisor-details-map storm-cluster-state) 

24 33 construct the final Assignments by adding start-times etc into it 

25 new-assignments (into {} (for [[topology-id executor->node+port] topology->executor->node+port 

26 :let [existing-assignment (get existing-assignments topology-id) 

27 all-nodes (->> executor->node+port vals (map first) set) 

28 node->host (->> all-nodes 

29 (mapcat (fn [node] 

30 (if-let [host (.getHostName inimbus basic-supervisor-details-map node) ] 

31 [[node host] ] 

32 ))) 

33 (into {})) 

34 all-node->host (merge (:node->host existing-assignment) node->host) 

35 reassign-executors (changed-executors (:executor->node+port existing-assignment) 
executor->node+port) 

36 start-times (merge (:executor->start-time-secs existing-assignment) 

37 (into {} 

38 (for [id reassign-executors ] 

39 [id now-secs] 

40 )))]] 

41 {topology-id (Assignment. 


42 (master-stormdist-root conf topology-id) 


AS = 
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43 (select-keys all-node->host all-nodes) 
44 executor->node+port 
45 start-times)}))] 
46 
47 (doseq [[topology-id assignment] new-assignments 
48 :let [existing-assignment (get existing-assignments topology-id) 
49 topology-details (.getById topologies topology-id)]] 
50 (if (= existing-assignment assignment) 
51 (log-debug "Assignment for " topology-id " hasn't changed") 
52 (do 
53 (log-message "Setting new assignment for topology id " topology-id ": " (pr-str assignment)) 
54 (.set-assignment! storm-cluster-state topology-id assignment) 
55 ))) 
56 (->> new-assignments 
57 (map (fn [[topology-id assignment] ] 
58 (let [existing-assignment (get existing-assignments topology-id)] 
59 [topology-id (map to-worker-slot (newly-added-slots existing-assignment assignment))] 
60 
61 (into (]) 
62 (.assignSlots inimbus topologies)) 
63. )) 


在 mk-assignments 方 法 中 ， 主 要 涉及 两 个 参数 ， 具 体 如 下 所 示 。 

C) nimbus: nimbus-data 对 象 。 

O :scratch-topology-id: 需要 进行 重新 调度 的 Topology 的 id， 也 即 storm-id。 

下 面 我 们 来 分 析 一 下 代码 。 

a 第 2~4 行 分 别 从 nimbus-data 中 获取 conf、storm-cluster-state 和 inimbus 对 象 并 将 其 保存 

为 临时 变量 。 

口 第 6 行 获取 当前 所 有 活跃 的 Topology 的 id 集 合 。 

口 第 7~8 行 根据 前 面 获取 到 的 活跃 topology-id 集 合 , 对 每 一 个 id 调 用 read-topology-details 

方法 ， 获 取 TopologyDetails 信 息 并 返回 <storm-id，TopologyDetails> 集 合 。 

a 第 9 行 利用 前 面 返回 的 <storm-id，TopologyDetails> 集 合 创 建 Topologies 对 象 。 

口 第 11 行 获取 所 有 已 经 分 配 资源 的 Topology 的 id 集合 。 

口 第 12~14 行 根据 前 面 得 到 的 已 分 配 资源 的 topology-id 集 合 , 获取 其 中 每 个 Toplogy 的 任务 分 
配 结果 assignments， 并 返回 <storm-id，Assignment> 集 合 。 注 意 ， 对 于 需要 重新 调度 的 
Topology ( 由 scratch-topology-id 指 定 )， 这 里 将 不 会 去 获取 它 的 assignments， 其 所 有 的 
slots 也 都 会 被 视 为 可 用 资源 。 

a 第 16~20 行 调用 compute-new-topology->executor->node+port 方 法 为 所 有 的 Topology 计 算 

新 的 调度 ， 并 返回 topology->executor->node+port。 我 们 会 在 后 面 对 该 方法 进行 介绍 。 

a 第 22 行 获取 当前 系统 时 间 ( 转化 成 秒 )。 

口 第 23 行 调用 basic-supervisor-details-map 方 法 获取 ZooKeeper 中 所 有 的 SupervisorInfo 

言 息 ， 然 后 将 其 转换 为 <supervisor-id，SupervisorDetails> 集 合 。 

a 第 25~45 行 对 前 面 第 16~20 行 返回 的 topology->executor->node+port 中 的 每 一 项 进行 处 理 ， 
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最 终 的 返回 值 是 新 计算 得 到 的 <topology-id，Assignment> 集 合 。 

a 第 26 行 根据 topology-id 从 第 12~14 行 返回 的 <storm-id，Assignment> 集 合 中 获取 Topology 

的 任务 分 配 情况 。 

O 第 27 行 根据 executor->node+port 信 息 提取 其 中 所 有 的 节点 信息 。 

a 第 28~33 行 根据 第 27 行 返回 的 node 集 合 ， 尝 试 获取 每 一 个 节点 的 主机 名 信息 ， 并 返回 一 个 

<node，hostname> 集 合 。 

口 第 34 行 会 将 从 第 26 行 获取 的 assignment 中 的 <node，host> 集 合 ， 跟 从 第 28~33 行 获取 的 
<node，hostname> 集 合 进行 合并 ， 得 到 所 有 的 <node，host> 关 系 。 如 果 存 在 相同 的 node， 
那么 与 其 对 应 的 主机 名 将 采用 <node，, hostname> 和 集合 中 的 值 ， 即 以 从 第 28 ~ 33 行 获取 的 信 
息 为 准 。 

口 第 35 行 调用 changed-executors 方 法 ， 通 过 将 第 26 行 返回 的 assignment 中 的 
executor->node+port 信 息 同 新 计算 得 到 的 executor->node+port 信 息 进行 对 比 ， 计 算出 所 
有 被 重新 分 配 的 Executor。 

O 第 36~40 行 通过 将 已 经 存在 的 assignment 中 的 executor->start-time-secs 信 息 与 所 有 被 重 
新 分 配 的 executor->start-time-secs 信 息 (它们 的 start-time-secs 为 当前 时 间 ) 进行 合 
并 ， 获 得 最 新 的 所 有 <executor ，start-time-secs> 集 合 。 

a 第 41~45 行 创建 新 的 Assignment 对 象 。 其 参数 分 别 是 该 Topology 在 Nimbus 服 务 器 上 的 root 
文件 夹 路 径 、<node, host> 和 集合、 新 的 executor->node+port 映 射 关 系 集合 以 及 新 的 executor 
->start-time-secs 映 射 关系 集合 。 

O 第 47~55 行 对 于 前 面 返回 的 新 计算 的 ctopology-id，Assignment> 集 合 中 的 每 一 项 ， 比 较 其 
新 调度 ( new-assignments ) 跟 目 前 调度 ( existing-assignments ) 之 间 是 否 发 生 了 变化 。 
如 果 没 有 ， 就 打印 一 条 记录 ; 如 果 有 ， 则 将 该 Topology 在 ZooKeeper 中 保存 的 调度 结果 更 
新 为 new-assignments。 

口 第 56~63 行 对 于 前 面 返回 的 new-assignments 中 的 每 一 项 ， 首 先 计 算出 新 增加 的 slot ( 通过 将 
new-assignments 中 的 node+port 减 去 existing-assignments 中 的 node+port 得 到 )， 再 将 其 转化 
为 worker-slot 对 象 ， 返 回 的 是 <topology-id，WMorkerSlot> 集 合 ， 最 后 调用 inimbus 的 
assignSlots 方 法 来 分 配 slot( 貌似 现在 这 一 步 没 什么 用 , 这 个 assignSlots 方 法 什么 都 没 做 )。 


6.3.2 do-cleanup 


该 方法 用 于 判断 哪些 Topology 需 要 清理 , 并 对 需要 清理 的 Topology 进 行 相 应 的 操作 。 do-cleanup 
会 首先 删除 这 些 Topology 保 存在 ZooKeeper 中 的 心跳 及 错误 信息 ， 然 后 尝试 清除 Nimbus 本 地 目录 中 
的 相关 文件 ， 并 从 Nimbus 心 跳 缓存 中 移 除 对 应 的 信息 。do-cleanup 方 法 的 代码 如 下 所 示 : 


1 (defn do-cleanup [nimbus] 

2 (let [storm-cluster-state (:storm-cluster-state nimbus) 
3 conf (:conf nimbus) 

4 submit-lock (:submit-lock nimbus)] 
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5 (let [to-cleanup-ids (locking submit-lock 

6 (cleanup-storm-ids conf storm-cluster-state))] 

7 (when-not (empty? to-cleanup-ids) 

8 (doseq [id to-cleanup-ids] 

9 (log-message "Cleaning up " id) 

10 (.teardown-heartbeats! storm-cluster-state id) 
11 (.teardown-topology-errors! storm-cluster-state id) 
12 (try 

13 (xmr (master-stormdist-root conf id)) 

14 (catch Exception e (log-warn (.getMessage e)))) 
15 (swap! (:heartbeats-cache nimbus) dissoc id)) 
16 )))) 


6.3.3 clean-inbox 


该 方法 负责 清理 Nimbus 的 inbox 文 件 夹 (其 路 径 是 STORM-LOCAL-DIRmimbus/inbox )， 清 理 
的 条 件 是 从 jar 包 最 后 一 次 被 修改 到 当前 时 间 的 间隔 超过 了 NIMBUS-INBOX-JAR-EXPIRATION-SECS 的 
限定 ( 默认 是 3600 秒 )。 该 方法 的 代码 如 下 : 


(defn clean-inbox [dir-location seconds] 
"Deletes jar files in dir older than seconds." 
(let [now (current-time-secs) 
pred #(and (.isFile %) (file-older-than? now seconds %)) 
files (filter pred (file-seq (File. dir-location)))] 
(doseq [f files] 
(if (.delete f) 
(log-message "Cleaning inbox ... deleted: " (.getName f)) 
33 This should never happen 
(log-error "Cleaning inbox ... error deleting: " (.getName f)) 


0) 


6.4 Topology 状态 转移 


Nimbus 需 要 监视 当前 所 有 Topology 的 状态 ， 并 根据 收 到 的 Topology 状 态 转移 请 求 〈 如 kill、 
rebalance, 、activate 和 deactivate 等 ) 完成 相应 的 状态 转换 。 在 Nimbus 中 , 我们 定义 了 通用 的 状态 转 
移 方法 , 它们 会 根据 传人 的 转移 事件 做 相应 的 处 理 , 这 些 方法 包括 transition-namel , transition! 


和 state-transitions。 


PO ON AU RWN Pp 


e 
e O 


6.4.1 transition-name! 


该 方法 会 根据 topology-name 及 对 应 的 转移 


二 


事件 完成 Topology 的 状态 转换 ， 相 关 代码 如 下 : 


1 defn transition-name! [nimbus storm-name event & args] 

2 (let [storm-id (get-storm-id (:storm-cluster-state nimbus) storm-name)] 
3 (when-not storm-id 

4 (throw (NotAliveException. storm-name))) 

5 (apply transition! nimbus storm-id event args))) 
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这 个 方法 很 简单 ， 首 先 它 通过 调用 get-storm-id 方 法 ， 为 传人 的 storm-name 查 找 对 应 的 
storm-id， 如 果 找 到 了 ， 就 调用 transition! 方 法 。 所 以 它 的 作用 实际 上 就 是 将 基于 storm-name 的 
状态 转换 为 基于 storm-id 的 状态 。 


6.4.2 transition! 


transition! 方 法 会 根据 传人 的 转移 事件 , 获取 与 当前 Topology 状 态 对 应 的 状态 转换 函数 ,并 
执行 该 函数 取得 转换 后 的 新 状态 。 如 果 新 状态 不 为 空 ， 则 将 其 更 新 到 ZooKeeper 中 。 该 方法 的 代 
人 码 如 下 : 


1 (defn transition! 

2 ([nimbus storm-id event] 

3 (transition! nimbus storm-id event false)) 

4 ([nimbus storm-id event error-on-no-transition?] 
5 (locking (:submit-lock nimbus) 

6 (let [system-events #{:startup} 

7 [event & event-args] (if (keyword? event) [event] event) 

8 status (topology-status nimbus storm-id)] 

9 ;; handles the case where event was scheduled but topology has been removed 
1 

1 


0 (if-not status 

1 (log-message "Cannot apply event " event " to " storm-id " because topology no 
longer exists") 

12 (let [get-event (fn [m e] 

13 (if (contains? m e) 

14 (m e) 

15 (let [msg (str "No transition for event: " event 

16 ", status: " status, 

17 " storm-id: " storm-id)] 

18 (if error-on-no-transition? 

19 (throw-runtime msg) 

20 (do (when-not (contains? system-events event) 

21 (log-message msg)) 

22 nil)) 

23 

24 transition (-» (state-transitions nimbus storm-id status) 

25 (get (:type status)) 

26 (get-event event)) 

27 transition (if (or (nil? transition) 

28 (keyword? transition)) 

29 (fn [] transition) 

30 transition) 

31 new-status (apply transition event-args) 

32 new-status (if (keyword? new-status) 

33 {:type new-status} 

34 new-status) ] 

35 (when new-status 

36 (set-topology-status! nimbus storm-id new-status))))) 

37 ))) 


a 第 2~3 行 是 一 个 重 载 方法 ， 它 会 直接 调用 第 4 行 的 方法 。 默 认 的 参数 false 表 示 在 找 不 到 对 
应 的 转换 方式 时 将 不 抛 出 异常 。 
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a 第 5 行 尝 试 获 取 nimbus-data 的 submit-lock。 为 了 提高 Nimbus 的 处 理性 能 ， 在 storm 所 采取 
的 处 理 模 式 中 ( 后 面 介绍 state-transition 时 我 们 会 说 明 这 一 点 )， 无 论 是 Nimbus 的 主 服 
务 线程 还 是 计时 器 线程 都 会 调用 transition 方 法 。 因 此 为 了 确保 逻辑 的 正确 性 ,必须 在 这 
里 做 同步 。 

O 第 6 行 定 义 了 一 个 system-events 集 合 ， 它 只 包含 :startup。 

a 第 7 行 判断 event 是 否 是 keyword ( 以 “:” 开 头 )。 如 果 是 ， 会 返回 event 的 一 个 集合 形式 ; 
如 果 不 是 ， 则 照 原样 返回 。 其 中 ， 第 一 个 参数 绑 定 为 event， 即 转移 事件 ; 剩 下 的 参数 则 
绑 定 为 event-args， 它 是 转移 事件 所 对 应 的 状态 转换 函数 的 参数 。 

O 第 8 行 调用 topology-status 来 获取 Topology 当 前 的 运行 状态 。 

a 在 第 10~11 行 中 如 果 没 有 找到 Topology 的 运行 状态 ， 即 Topology 已 被 移 除 ， 那 么 打印 日 志 

并 结束 处 理 ， 否 则 就 继续 执行 下 面 的 代码 。 

O 第 12~23 行 定义 了 get-event 方 法 ,该 方法 会 根据 键 从 一 个 哈 希 表 中 查找 对 应 的 状态 转换 函 
数 。 如 果 没 能 找到 ， 则 将 这 一 情况 记录 下 来 并 根据 error-on-no-transition 的 设置 做 相应 


的 处 理 。 
O 第 24~26 行 首先 调用 state-transitions 方 法 获取 所 有 的 状态 跟 状 态 间 的 转移 事件 C 即 一 个 
PER, 键 是 原状 态 , 值 是 一 个 从 转移 事件 到 状态 转移 函数 的 哈 希 表 ), 然后 根据 Topology 


的 状态 找到 对 应 的 从 转移 事件 到 状态 转移 函数 的 哈 希 表 ， 最 后 调用 get-event 方 法 根据 传 
入 的 转移 事件 获取 状态 转换 函数 。 

O 第 27~30 行 对 前 面 获取 的 状态 转移 函数 进行 处 理 。 如 果 该 函数 为 空 (也 即 不 需要 转移 ) 或 
者 该 函数 是 一 个 关键 字 ( 直接 返回 转移 后 的 新 状态 )， 那 么 就 用 一 个 函数 对 其 进行 封装 ， 


否则 不 做 处 理 。 
a 第 31 行 直接 调用 前 面 处 理 过 的 状态 转移 函数 , 并 根据 传人 的 event-args 参 数 , 获取 转移 后 
的 新 状态 。 


O 第 32~34 行 对 得 到 的 新 状态 进行 判断 。 如 果 它 是 关键 字 ( keyword )， 那 么 将 它 封 装 成 一 个 
哈 希 表 ， 刍 是 :type; 否则 就 不 做 任何 处 理 。 
a 第 35~36 行 判断 新 的 状态 是 否 为 空 , 若 不 为 空 , 则 更 新 这 个 Topology 在 ZooKeeper 中 保存 的 
状态 。 


6.4.3 state-transitions 


state-transitions 方 法 定义 了 一 个 状态 转移 矩阵 , 它 的 键 集合 包括 :active、 :inactive、 :killed 
以 及 :rebalancing, 它们 表示 当前 Topology 所 处 的 全 部 起 始 状 态 , 它 的 值 定义 了 Topology 处 于 由 键 
§ 定 的 状态 时 ,其 状态 变化 需要 遵循 的 从 转移 事件 到 对 应 状态 转移 函数 的 映射 集合 。 其 相关 代码 
如 下 : 


1 defn state-transitions [nimbus storm-id status] 
2 {:active {:inactivate :inactive 
3 :activate nil 
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4 :rebalance (rebalance-transition nimbus storm-id status) 
5 :kill (kill-transition nimbus storm-id) 

6 

7 :inactive {:activate :active 

8 :inactivate nil 

9 :rebalance (rebalance-transition nimbus storm-id status) 
10 :kill (kill-transition nimbus storm-id) 

11 } 

12  :killed {:startup (fn [] (delay-event nimbus 

13 storm-id 

14 (:kill-time-secs status) 

15 :remove) 

16 nil) 

17 :kill (kill-transition nimbus storm-id) 

18 :remove (fn [] 

19 (log-message "Killing topology: " storm-id) 
20 (.remove-storm! (:storm-cluster-state nimbus) 
21 storm-id) 

22 nil) 

23 

24  :rebalancing {:startup (fn [] (delay-event nimbus 

25 storm-id 

26 (:delay-secs status) 

27 :do-rebalance) 

28 nil) 

29 :kill (kill-transition nimbus storm-id) 

30 :do-rebalance (fn [] 

31 (do-rebalance nimbus storm-id status) 

32 (:old-status status)) 

33 H) 


O 第 2~6 行 表示 当 Topology 的 状态 为 :active 时 , 该 Topology 正 在 运行 。:inactivate 事 件 会 使 
Topology 状 态 转 移 到 :inactive，:activate 事 件 不 会 改变 Topology 的 状态 ，:rebalance 事 
{4-4 Arebalance-transitionPEZX, :killsf fih Azkill-transitionPR Zi, 

口 第 7~11 行 表示 当 Topology 的 状态 为 :inactive 时 ， 该 Topology 已 经 停止 运行 。:activate 事 件 
会 使 Topology 状 态 转 移 到 :active，:inactivate 事 件 不 会 改变 Topology 的 状态 ，:rebalance 
事件 会 触发 rebalance-transition 函 数 ，:kill 事 件 则 会 触发 Kil1-transition 函 数 。 

O 第 12~23 行 表示 当 Topology 的 状态 为 :killed 时 ， 该 Topology 已 经 被 删除 ， 但 ZooKeeper 中 
的 相关 数据 依然 没 被 删除 。: startup 事 件 会 触发 delay-event 函 数 , 此 时 Topology 的 状态 并 
不 会 发 生 改 变 。:kil1 事 件 会 触发 kil1-transition 函 数 。:remove 事 件 则 会 触发 其 对 应 的 fn 
函数 , 用 于 将 该 Topology 的 信息 从 ZooKeeper 中 删除 , 这 种 情况 下 返回 nil 信 号 只 是 为 了 确 
保 Storm 不 会 在 ZooKeeper 中 设置 该 Topology 的 状态 。 

O 第 24~32 行 表示 当 Topology 的 状态 为 :rebalancing 时 ，Storm 正 准备 为 该 Topology 重 新 分 配 
资源 。:startup 事 件 会 触发 delay-event 函 数 , 此 时 Topology 的 状态 并 不 会 发 生 改 变 , :kill 
Se MU) fil kill-transitioneAXt, :do-rebalanceSt +2 fii Kdo-rebalancerkiat, ŽA 
行 完 成 后 会 将 Topology 状 态 设置 为 进行 rebalance 操 作 之 前 的 状态 。 
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看 到 这 里 ， 估 计 很 多 人 会 觉得 奇怪 ， 为 什么 Storm 中 会 有 :killed 和 :rebalancing 这 两 个 状态 
呢 。 按 照 正 常 的 逻辑 ， 删 除 一 个 Topology 后 根本 不 需要 再 去 关心 它 的 状态 ， 进 行 rebalance 操 作 ， 
然后 返回 之 前 的 状态 就 可 以 了 ， 因 此 这 两 个 状态 貌似 有 点 画蛇添足 。 但 实际 上 Storm 这 样 做 是 有 
其 用 意 的 : 为 了 提高 Nimbus 的 处 理 速 度 ， 很 多 操作 都 被 分 为 两 步 来 执行 ，Nimbus 的 主 服 务 线程 
往往 只 是 将 这 些 事件 转发 后 便 立 即 返 回 , 具体 的 操作 则 都 交 由 计时 器 线程 来 完成 。 下 面 我 们 来 分 
析 kill-transition 和 rebalance-transition 方 法 ,相信 和 看 完 这 两 个 方法 大 家 就 会 明白 Storm 这 样 设 
计 的 用 意 了 。 

在 分 析 之 前 ， 我 们 先 看 一 下 delay-event 方 法 ， 这 个 方法 在 kill-transition 和 rebalance- 
transition 中 都 用 到 了 o 

delay-event 方 法 表示 延迟 一 段 时 间 后 再 处 理 转移 事件 ， 其 参数 包括 nimbus-data、storm-id、 
延迟 执行 的 时 间 及 转移 事件 。 它 实际 上 就 是 通过 简单 调用 schedule 方 法 (这 个 方法 在 第 4 章 介 绍 
过 ) 将 创建 的 匿名 函数 加 入 到 Nimbus 计 时 器 线程 的 优先 级 队列 中 。 而 这 个 匿名 函数 就 是 调用 
transition! 方 法 来 处 理 转移 事件 。 该 方法 的 代码 如 下 : 


1 (defn delay-event [nimbus storm-id delay-secs event] 

2 (log-message "Delaying event " event " for " delay-secs " secs for " storm-id) 
3 (schedule (:timer nimbus) 

4 delay-secs 

5 #(transition! nimbus storm-id event false) 

6 


kil1-transition 方 法 定义 了 一 个 方法 ， 其 参数 是 kil1-time， 即 做 真正 的 Kill 操作 之 前 需要 等 
待 的 时 间 ， 其 代码 如 下 : 


1 (defn kill-transition [nimbus storm-id] 

2 (fn [kill-time] 

3 (let [delay (if kill-time 

4 kill-time 

5 (get (read-storm-conf (:conf nimbus) storm-id) 
6 TOPOLOGY -MESSAGE - TIMEOUT - SECS) ) ] 
7 (delay-event nimbus 

8 storm-id 

9 delay 

10 :remove) 

11 (:type :killed 

12 :kill-time-secs delay}) 


13 )) 


口 第 3~6 行 获取 要 等 待 的 时 间 。 如 果 传 人 的 kil1l-time 不 为 空 ， 就 采用 kil1-time， 和 否则 将 使 
用 TOPOLOGY-MESSAGE-TIMEOUT-SECS 作 为 默认 值 。 

O 第 7~10 行 调用 delay-event 方 法 ，event 被 设置 为 :remove， 延 迟 时 间 被 设置 为 前 面 计算 的 
等 待 时 间 。 

口 第 11~12 行 返回 方法 执行 的 结果 ， 其 中 Topology 的 状态 被 设置 成 了 :killed。 aan 
只 有 等 到 加 入 计时 器 线程 的 方法 执行 完 后 (在 :killed 状 态 下 执行 :remove 转 移 事件 )，j 
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Topology 在 ZooKeeper 中 的 数据 才 会 被 真正 删除 。 由 于 这 一 步 是 在 计时 需 线 程 中 执行 的 ， 
此 从 总 体 上 说 ，Nimbus 的 处 理性 能 得 到 了 提高 。 
与 kil1l-transition 类 似 ，rebalance-transition 也 返回 了 一 个 方法 ， 其 代码 如 下 : 


1 (defn rebalance-transition [nimbus storm-id status] 
2 (fn [time num-workers executor-overrides] 

3 (let [delay (if time 

4 time 

5 (get (read-storm-conf (:conf nimbus) storm-id) 
6 TOPOLOGY -MESSAGE - TIMEOUT - SECS) ) ] 

7 (delay-event nimbus 

8 storm-id 

9 delay 

10 :do-rebalance) 

11 (:type :rebalancing 

12 :delay-secs delay 

13 :old-status status 

14 :num-workers num-workers 

15 :executor-overrides executor-overrides 

16 Dp» 


返回 的 fn 函数 的 参数 有 3 个 ， 具 体 如 下 所 示 。 

O time: 即 在 执行 rebalance 操 作 之 前 需要 延迟 的 时 间 。 

O num-workers: rebalance 操 作 设置 的 新 的 num-workers。 

口 executor-overrrides: rebalance 操 作 设 置 的 新 的 从 组 件 到 Executor 数 目的 哈 希 表 。 

O 同 kill-transition 类 似 ， 第 3~6 行 也 是 获取 等 待 时 间 。 

a 第 7~10 行 调用 delay-event 方 法 , event 被 设置 为 :do-rebalance, 延迟 时 间 被 设置 为 前 面 计 

算得 到 的 等 待 时 间 。 

a 第 11~15 行 返回 执行 结果 。Topology 的 状态 被 更 新 为 :rebalancing， 表明 rebalance 操 作 正 在 进 
行 中 。 等 到 加 入 计时 带 线 程 的 方法 执行 后 (在 :rebalancing 状 态 下 执行 :do-rebalance 转 移 二 
件 ， 也 即 执行 do-rebalance 方 法 )， 该 Topology 的 rebalance 操 作 才 算 真 正 完成 。 

最 后 简单 介绍 一 下 do-rebalance 方 法 ， 其 代码 如 下 : 


p 


1 (defn do-rebalance [nimbus storm-id status] 

2 (.update-storm! (:storm-cluster-state nimbus) 

3 storm-id 

4 (assoc-non-nil 

5 {:component->executors (:executor-overrides status) } 
6 :num-workers 

7 (:num-workers status))) 

8 (mk-assignments nimbus :scratch-topology-id storm-id)) 


该 方法 首先 将 rebalance 设 置 的 参数 更 新 到 ZooKeeper 中 , 然后 调用 mk-assignments 方 法 重新 调 
度 任务 。 这 里 将 :scratch-topology-id 设 置 为 需要 执行 rebalance 操 作 的 Topology 的 id， 这 表明 对 
于 这 个 Topology， 当 前 占有 的 所 有 资源 在 分 配 时 都 可 以 看 作 是 可 用 的 。 这 点 在 前 面 讲述 
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mk-assignments 时 曾经 介绍 过 。 


图 6-2 描 述 了 与 state-transition 方 法 相对 应 的 状态 转移 图 。 
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6.5 启动 Nimbus 服务 


局 动 Nimbus 服 务 主 要 涉及 
的 启动 人 口 ， 而 后 者 则 是 真正 定义 处 理 逻 辑 的 地 方 。 


ze Nimbus 


6.5.1 launch-server! 


该 方法 是 Nimbus 服 务 的 启动 入 口 。 它 定义 了 核心 的 处 理 逻 辑 ， 构 建 起 一 个 THsHaServer， 并 
最 终 启 动 Nimbus 服 务 ， 其 代码 如 下 : 


1 (defn launch-server! [conf nimbus] 
2 (validate-distributed-mode! conf) 
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3 (let [service-handler (service-handler conf nimbus) 

4 options (-» (TNonblockingServerSocket. (int (conf NIMBUS-THRIFT-PORT))) 

5 (THsHaServer$Args.) 

6 (.workerThreads 64) 

7 (.protocolFactory (TBinaryProtocol$Factory.)) 

8 (.processor (Nimbus$Processor. service-handler)) 

9 ) 

10 server (THsHaServer. options)] 

11 (.addShutdownHook (Runtime/getRuntime) (Thread. (fn [] (.shutdown service-handler) (.stop 
server)))) 

12 (log-message "Starting Nimbus server...") 

13 (.serve server))) 


launch-server! 的 输入 参数 有 以 下 两 个 。 

口 conf: 配置 项 。 

口 nimbus; 一 个 实现 了 INimbus 接 口 的 对 象 。 
下 面 简要 介绍 各 行 代码 的 作用 。 
a 第 2 行 验证 当前 系统 是 否 处 于 分 布 式 模式 ， 因 为 只 有 处 于 分 布 式 模 式 时 才能 够 这 样 启动 


Nimbus 服务 。 
O 第 3 行 定义 了 service-handler 方 法 。 顾名思义 , 它 是 Nimbus 真 正人 处 理 请 求 的 地 方 , 后 面 我 
们 会 介绍 该 方法 。 


a 第 4~9 行 定义 了 用 于 启动 Thrift ThsHaServer 的 参数 , 其 中 指定 了 服务 器 的 端口 号 是 NIMBUS- 
THRIFT-PORT，Worker 线 程 池 的 线程 数目 是 64， 使 用 的 协议 是 TBinaryProtocol， 并 以 第 3 
行 定 义 的 service-handler 作 为 该 服务 絮 的 处 理 器 。 

口 第 10 行 使 用 前 面 定义 的 参数 创建 ThsHaServer。 

a 第 11 行 为 当前 JVM 添 加 一 个 关闭 的 钩子 ， 该 钩子 实际 上 是 已 被 初始 化 但 还 没有 开始 执行 
的 线程 对 象 。 当 JVM 将 要 停止 时 ， 这 些 钓 子 便 开始 执行 ， 完 成 诸如 停止 service-handler 
和 关闭 ThsHaserver 之 类 的 清理 工作 。 

O 第 13 行 调用 THsHaServer 的 serve 方 法 来 启动 服务 。 至 此 ，Nimbus 服务 就 算是 成 功 启 动 了 ， 

接 下 来 我 们 便 可 开始 进行 提交 Topology 等 例 行 操作 了 。 


6.5.2 service-handler 


service-handler 方 法 是 Nimbus 真 正 处 理 请 求 的 地 方 ， 它 首先 定义 了 一 些 必要 的 数据 结构 ， 
以 及 用 于 启动 任务 调度 和 数据 清理 的 线程 ， 其 次 ， 它 还 会 返回 一 个 实现 了 Nimbus$Iface 接 口 、 
Shutdownable 接 口 以 及 DaemonCommon 接 口 的 对 象 ，Nimbus 负 责 处 理 请 求 信息 的 逻辑 都 包含 在 这 个 
对 象 中 。 

下 面 我 们 来 看 一 个 这 个 方法 的 具体 实现 : 


1 (defserverfn service-handler [conf inimbus] 
2 (.prepare inimbus conf (master-inimbus-dir conf)) 
3 (log-message "Starting Nimbus with conf " conf) 
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4 (let [nimbus (nimbus-data conf inimbus) ] 

5 (cleanup-corrupt-topologies! nimbus) 

6 (doseq [storm-id (.active-storms (:storm-cluster-state nimbus))] 
7 (transition! nimbus storm-id :startup)) 

8 (schedule-recurring (:timer nimbus) 


9 0 

10 (conf NIMBUS-MONITOR-FREQ-SECS) 

11 (fn [] 

12 (when (conf NIMBUS-REASSIGN) 

13 (locking (:submit-lock nimbus) 
14 (mk-assignments nimbus))) 
15 (do-cleanup nimbus) 

16 )) 

17 33 Schedule Nimbus inbox cleaner 

18 (schedule-recurring (:timer nimbus) 

19 0 

20 (conf NIMBUS-CLEANUP - INBOX- FREQ- SECS) 

21 (fn [] 

22 (clean-inbox (inbox nimbus) (conf NIMBUS-INBOX-JAR-EXPIRATION-SECS)) 
23 

24 (reify Nimbus$Iface 

> (详细 实现 后 面 我 们 会 介绍 ) 

26 Shutdownable 

27 

28 DaemonCommon 

29 (waiting? [this] 

30 (timer-waiting? (:timer nimbus)))))) 


该 方法 涉及 的 参数 有 如 下 两 个 。 

口 conf: Nimbus 使 用 的 配置 信息 。 

口 inimbus: standalone-nimbus 对 象 。 

下 面 简要 介绍 该 方法 中 各 行 代码 的 含义 。 

a 第 2 行 调用 inumbus 的 prepare 方 法 ， 目 前 的 实现 中 这 个 prepare 方 法 为 空 。 

a 第 4 行 调用 nimbus-data 方 法 构建 Nimbus 数 据 结构 ， 这 个 结构 的 具体 内 容 已 在 前 面 介绍 过 。 

口 第 5 行 调用 cleanup-corrupt-topologies! 方 法 清除 那些 在 ZooKeeper 上 还 有 元 数据 但 在 Nimbus 

本 地 目录 中 没有 对 应 文件 夹 的 Topology， 将 它们 遗留 在 ZooKeeper 中 的 记录 彻底 删除 掉 。 

口 第 6~7 行 对 当前 所 有 处 于 活跃 状态 的 Topology 调 用 transition! 方 法 ,设置 Topology 的 状态 。 

这 里 将 转移 事件 设置 为 :start-up。 

O 第 8~23 行 使 用 nimbus-data 中 的 计时 需 线 程 调度 mk-assignments 方 法 、do-cleanup 方 法 及 
clean-inbox 方 法 。 这 里 要 注意 的 是 ，mk-assignments 方 法 只 有 在 Storm 配 置 项 中 
NIMBUS-REASSIGN 为 true ( 默认 是 true ) 时 才 会 执行 ， 且 在 执行 任务 分 配 时 需要 获 
取 :submit-lock 锁 对 象 ， 以 避免 任务 分 配 和 提交 新 Topology 这 两 项 操作 发 生 冲 突 。 

O 第 24~30 行 返回 一 个 实现 了 Nimbus$Iface、Shutdownable 和 DaemonCommon 接 口 的 对 象 , 该 对 
象 会 被 用 来 处 理 Nimbus 服 务 请 求 以 及 关闭 Nimbus 服 务 。 
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6.6 ”关闭 Nimbus 服务 


关闭 Nimbus 服 务 要 进行 的 操作 主要 包括 杀 掉 计时 需 线 程 ， 释 放 ZooKeeper 连 接 ， 以 及 清除 
nimbus-data 中 的 上 传 、 下 载 缓 存 。 其 实现 方法 如 下 : 


1 (shutdown [this] 

2 (log-message "Shutting down master") 

3 (cancel-timer (:timer nimbus)) 

4 (.disconnect (:storm-cluster-state nimbus)) 
5 (.cleanup (:downloaders nimbus)) 

6 (.cleanup (:uploaders nimbus)) 

7 (log-message "Shut down master") 

8 


) 
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下 面 我 们 对 Nimbus 的 主要 服务 方法 进行 分 析 。 它们 包括 Topology 的 提交 操作 、jar 文 件 的 上 传 
与 下 载 ， 以 及 UI 信息 、Storm 配 置 项 和 Topology 对 象 的 获取 等 基本 工作 。 所 涉及 的 源码 请 参考 


storm\sre\clj\backtype\storm\daemon\nimbus.clj。 


6.7.1 submitTopology 


该 方法 用 来 提交 一 个 新 的 Topology， 并 为 Topology 创 建 topology-id， 验 证 其 结构 ,设置 一 些 
必要 的 元 数据 ， 最 后 调用 mk-assignments 方 法 为 Topology 分 配 任务 。 其 代码 如 下 : 


1 (‘void submitTopologyWithOpts 


2 [this ‘String storm-name “String uploadedJarLocation “String serializedConf ^StormTopology 
topology ^SubmitOptions submitOptions] 

3 (try 

4 (assert (not-nil? submitOptions)) 

5 (validate-topology-name! storm-name) 

6 (check-storm-active! nimbus storm-name false) 

7 (.validate ^backtype.storm.nimbus.ITopologyValidator (:validator nimbus) 

8 storm-name 

9 (from-json serializedConf) 

10 topology) 

11 (swap! (:submitted-count nimbus) inc) 

12 (let [storm-id (str storm-name "-" @(:submitted-count nimbus) "-" (current-time-secs)) 

13 storm-conf (normalize-conf 

14 conf 

15 (-> serializedConf 

16 from-json 

17 (assoc STORM-ID storm-id) 

18 (assoc TOPOLOGY-NAME storm-name)) 

19 topology) 

20 total-storm-conf (merge conf storm-conf) 

21 topology (normalize-topology total-storm-conf topology) 

22 topology (if (total-storm-conf TOPOLOGY-OPTIMIZE) 


23 (optimize-topology topology) 
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24 topology) 
25 storm-cluster-state (:storm-cluster-state nimbus)] 
26 (system-topology! total-storm-conf topology) ;; this validates the structure of the 
topology 
27 (log-message "Received topology submission for " storm-name " with conf " storm-conf) 
28 ;; lock protects against multiple topologies being submitted at once and 
29 ;; Cleanup thread killing topology in b/w assignment and starting the topology 
30 (locking (:submit-lock nimbus) 
31 (setup-storm-code conf storm-id uploadedJarLocation storm-conf topology) 
32 (.setup-heartbeats! storm-cluster-state storm-id) 
33 (let [thrift-status-»kw-status {TopologyInitialStatus/INACTIVE :inactive 
34 TopologyInitialStatus/ACTIVE :active}] 
35 (start-storm nimbus storm-name storm-id (thrift-status-»kw-status 
(.get initial status submitOptions)))) 
36 (mk-assignments nimbus))) 
37 (catch Throwable e 
38 (log-warn-error e "Topology submission exception. (topology name='" 
storm-name "')") 
39 (throw e)))) 
40 


41 (^void submitTopology 
42 [this ^String storm-name “String uploadedJarLocation “String serializedConf ^StormTopology 


topology] 
43  (.submitTopologyWithOpts this storm-name uploadedJarLocation serializedConf topology 
44 (SubmitOptions. TopologyInitialStatus/ACTIVE))) 


这 里 主要 有 两 个 方法 : submitTopologyWithopts 和 submitTopology。 后 者 是 基于 前 者 实现 的 ， 
因此 两 个 方法 的 执行 过 程 类 似 ， 只 不 过 submitTopology 将 默认 的 Submitoptions 设 置 为 了 ACTIVE。 
通常 ， 我 们 提交 Topology 时 ， 都 是 直接 调用 submitTopology 方 法 。 

下 面 我 们 分 析 一 下 代码 。 

口 第 4 行 是 对 submitoptions 参 数 进行 验证 ， 这 个 参数 不 能 为 空 。 

a 第 5 行 调用 validate-topology-name! 来 确保 storm-name 中 不 含有 非法 字符 ， 目 前 的 非法 字 

符 集 定义 为 (seh t UNIS 

口 第 6 行 确保 当前 没有 一 个 跟 要 提交 的 Topology 同 名 ( storm-name ) 的 Topology 正 在 运行 。 

a 第 7~10 行 通过 调用 nimbus-data 中 的 validator 来 对 当前 要 提交 的 Topology 进 行 验证 ， 目 前 

使 用 的 DefaultValidator 实 际 上 什么 都 没 做 。 

O 第 11 行 用 于 更 新 nimbus-data 中 的 : ubmitted-count 参 数 (加 1 )。 

a 第 12 行 为 这 个 要 提交 的 Topology 创 建 全 局 唯一 的 storm-id, 也 即 topology-id, 它 的 格式 为 

<storm-name>-< 当 前 的 submitted-count>-< 当 前 时 间 ( 转化 成 秒 ) >, 

口 第 13~19 行 通过 调用 normalize-conf 方 法 获取 要 提交 的 Topology 的 Storm 配置 , 它 首先 对 传 
人 的 serializedConf 进 行 反 序列 化 操作 ， 然 后 加 入 storm-name 和 storm-id 人 信息， 最 后 再 加 
入 如 下 参数 : TOPOLOGY-KRYO-DECORATORS , TOPOLOGY-KRYO-REGISTER , TOPOLOGY-ACKER- 
EXECUTORS 、TOPOLOGY-MAX-TASK-PARALLELISM。 这 里 如 果 用 户 的 配置 中 指定 了 TOPOLOGY- 
KRY0-DECORATORS 和 TOPOLOGY-KRYO-REGISTER，Storm 会 优先 使 用 用 户 的 配置 。 
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a 第 20 行 将 Storm 默认 的 配置 项 和 前 面 获取 的 Storm 配 置 项 合并 ( 其 实 主要 是 加 入 前 面 获取 

的 Storm 配 置 项 中 没有 的 但 是 Storm 上 默认 配置 项 中 存在 的 配置 项 )。 

口 第 21 行 调用 normalize-topology 处 理 Topology, 更 新 Topology 中 所 有 组 件 的 TOPOLOGY-TASKS 

配置 项 ， 本 章 后 面 会 介绍 该 方法 。 

口 第 22~24 行 通过 判断 配置 项 中 TOPOLOGY-0PTIMIZE 是 否 为 true 来 选择 是 否 需 要 对 Topology 进 
行 优 化 (实际 上 ，Storm 目 前 还 没有 这 一 优化 的 具体 实现 ， 即 使 配置 为 true， 
optimize-topology 也 是 什么 都 没 做 )。 

O 第 25 行 获取 nimbus-data 中 的 :storm-cluster-state 对 象 , 并 将 其 存储 为 临时 变量 供 后 面 使 用 。 

口 第 26 行 通过 调用 system-topology! 方 法 对 Topology 结 构 进 行 验证 ,我 们 会 在 后 面 介绍 该 方法 。 

a 第 30 行 尝试 获取 nimbus-data 的 :submit-lock 锁 。 

口 第 31 行 调用 setup-storm-code 为 该 Topology 创 建 对 应 的 本 地 文件 夹 , 复制 .jar 文件 , 并 写 入 

序列 化 后 的 Storm 配 置 项 和 Topology 信 息 。 

a 第 32 行 为 该 Topology 在 ZooKeeper 中 创建 心跳 路 径 ， 路 径 是 /storm/workerbeats/topology-id。 

a 第 33~34 行 定义 了 一 个 从 thrift-status 到 keyword-status 的 哈 希 表 ， 这 个 哈 希 表 会 被 用 来 

将 传人 的 supmitoptions 中 的 thrift-status 转 化 为 对 应 的 keyword-status。 

口 第 35 行 调用 start-storm 方 法 设置 stormBase ， 它 在 ZooKeeper 中 的 路 径 是 /storm/storms/ 

<topology-id>，stormBase 的 信息 将 作为 该 路 径 所 对 应 的 值 存储 。 

口 第 36 行 调用 mk-assignments 为 新 提交 的 Topology 分 配 资源 ， 这 个 方法 我 们 已 经 介绍 过 。 


6.7.2 kill, rebalance, activate, deactivate 方法 


接 下 来 ,我 们 分 析 kil1、rebalance、activate 和 deactivate 方 法 的 实现 。 将 这 几 个 方法 放 在 
一 起 分 析 ， 主 要 是 因为 它们 都 依赖 于 前 面 介 绍 过 的 transition-name! 函 数 。 相 关 代码 如 下 : 


^void killTopolo this ^String name 
id killTopology [thi ing 
(.killTopologyWithOpts this name (KillOptions.))) 


1 

2 

3 

4 (^void killTopologyWithOpts [this ^String storm-name ^KillOptions options] 
5 (check-storm-active! nimbus storm-name true) 

6 (let [wait-amt (if (.is set wait secs options) 

7 (.get wait secs options) 

8 


)] 


9 (transition-name! nimbus storm-name [:kill wait-amt] true) 

10  )) 

11 

12 (^void rebalance [this ^String storm-name ^RebalanceOptions options] 
13 (check-storm-active! nimbus storm-name true) 

14 (let [wait-amt (if (.is set wait secs options) 

15 (.get wait secs options)) 

16 num-workers (if (.is set num workers options) 

17 (.get num workers options)) 

18 executor-overrides (if (.is set num executors options) 


19 (.get num executors options) 
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20 {})] 

21 (doseq [[c num-executors] executor-overrides] 

22 (when (<= num-executors 0) 

23 (throw (InvalidTopologyException. "Number of executors must be greater 
than 0")) 

24 )) 

25 (transition-name! nimbus storm-name [:rebalance wait-amt num-workers executor-overrides] 

true) 

26 )) 

27 

28 (activate [this storm-name] 

29 (transition-name! nimbus storm-name :activate true) 

30 ) 

31 

32  (deactivate [this storm-name] 

33 (transition-name! nimbus storm-name :inactivate true)) 


从 这 段 代码 可 以 看 到 这 些 方法 的 实现 基本 上 是 类 似 的 ,不同 的 只 是 kil1l1 和 rebalance 多 了 一 
些 必要 的 参数 而 已 。 
a 第 5 行 确保 提交 杀 掉 Topology 命 令 的 时 候 这 个 Topology 还 是 在 运行 着 的 。 
a 第 6~7 行 获取 要 延迟 多 少 秒 再 杀 掉 这 个 Topology。 这 个 时 间 是 用 户 可 以 指定 的 ， 如 果 没 有 
指定 ， 将 采用 Topology 的 消息 超时 时 间作 为 其 默认 值 。 
a 第 13 行 跟 第 5 行 做 了 同样 的 工作 。 
a 第 14~20 行 是 获取 需要 的 一 些 参 数 。 
口 第 21~24 行 用 于 验证 用 户 的 设 定 是 否 符 合 要 求 。 


6.7.3 ”文件 上 传 与 下 载 


Nimbus 作 为 一 个 服务 器 ， 一 方面 需要 接收 用 户 提交 的 Topology jar 包 ， 男 一 方面 还 要 问 
Supervisor 下 达 任 务 分 配 的 jar 包 ， 所 以 上 传 和 下 载 文件 的 功能 是 必需 的 。 

1. 文件 上 传 

文件 上 传 的 功能 是 通过 beginFileUpload、uploadChunk 和 finishFileUpload 这 3 个 方法 实现 的 ， 
相关 代码 如 下 : 


1 (beginFileUpload [this] 

2 let [fileloc (str (inbox nimbus) "/stormjar-" (uuid) ".jar")] 
3 (.put (:uploaders nimbus) 

4 fileloc 

5 (Channels/newChannel (FileOutputStream. fileloc))) 

6 (log-message "Uploading file from client to " fileloc) 

7 fileloc 

8 )) 

9 

10 (^void uploadChunk [this ^String location ^ByteBuffer chunk] 
11 (let [uploaders (:uploaders nimbus) 

12 ^WritableByteChannel channel (.get uploaders location)] 


13 (when-not channel 
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14 (throw (RuntimeException. 

15 "File for that location does not exist (or timed out)"))) 
16 (.write channel chunk) 

17 (.put uploaders location channel) 

18 )) 

19 

20 (^void finishFileUpload [this ^String location] 

21 (let [uploaders (:uploaders nimbus) 

22 ^WritableByteChannel channel (.get uploaders location)] 

23 (when-not channel 

24 (throw (RuntimeException. 

25 "File for that location does not exist (or timed out)"))) 
26 (.close channel) 

27 (log-message "Finished uploading file from client: " location) 
28 (.remove uploaders location) 

29 )) 


口 beginFileUpload 方 法 首先 会 创建 一 个 全 局 唯一 的 文件 名 ， 然 后 创建 一 个 新 的 WriteByte 

Channel， 并 将 此 关系 保存 到 nimbus-data 的 :uploaders 中 ， 然 后 返回 文件 路 径 。 

口 uploadChunk 方 法 首先 根据 文件 路 径 从 nimbus-data 的 :uploaders 中 找到 对 应 的 

WriteByteChannel， 然 后 把 ByteBuffer 中 的 数据 写 入 到 该 channel 中 。 

口 finishFileUpload 方 法 会 按照 文件 路 径 从 nimbus-data 的 :uploaders 中 找到 对 应 的 channel， 
将 其 关闭 并 将 此 文件 路 径 从 :uploaders 中 移 除 。 

2. 文件 下 载 

文件 下 载 是 由 beginFileDownload 和 downloadChunk 这 两 个 方法 实现 的 ， 相 关 代 码 如 下 : 


1 (^String beginFileDownload [this ^String file] 

2 (let [is (BufferFileInputStream. file) 

3 id (uuid)] 

4 (.put (:downloaders nimbus) id is) 

5 id 

6 )) 

7 

8 (^ByteBuffer downloadChunk [this ^String id] 

9 (let [downloaders (:downloaders nimbus) 

10 ^BufferFileInputStream is (.get downloaders id)] 
11 (when-not is 

12 (throw (RuntimeException. 

13 "Could not find input stream for that id"))) 
14 (let [ret (.read is)] 

15 (.put downloaders id is) 

16 (when (empty? ret) 

17 (.remove downloaders id)) 

18 (ByteBuffer/wrap ret) 

19 ))) 


口 beginFileDown1load 方 法 会 首先 打开 要 下 载 的 文件 ， 创 建 一 个 BufferFileInputStream 并 赋 
予 该 流 一 个 唯一 的 id, 然后 将 此 关系 保存 到 nimbus-data 的 :downloaders 中 , 返回 这 个 唯一 
的 id。 
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口 downloadChunk 方 法 首先 根据 id 从 nimbus-data 的 :downloaders 中 获取 对 应 的 BufferFile- 
InputStream， 然 后 从 该 流 中 读 取 数据 。 如 果 读 不 到 数据 ， 则 表明 数据 已 经 读 完 ， 此 时 会 
将 该 文件 从 :downloaders 中 移 除 。 


6.7.4 ”获取 UI 所 需 的 信息 


由 于 Nimbus 服 务 器 本 身 记 录 了 当前 集群 的 任务 分 配 和 调度 信息 ， 这 些 信息 需要 通过 UI 展 示 
给 用 户 ， 所 以 Nimbus$Iface 中 还 定义 了 获取 这 些 信息 的 接口 getClusterInfo 和 getTopologyInfo， 
下 面 简 要 介绍 这 两 个 方法 。 

1. etClusterInfo 

该 方法 用 来 获取 当前 集群 的 统计 信息 , 主要 包括 系统 资源 的 占用 情况 、Nimbus 服 务 运行 了 多 
长 时 间 ， 以 及 当前 系统 中 所 有 Topology 的 运行 统计 等 。 该 方法 的 代码 如 下 : 


1 (^ClusterSummary getClusterInfo [this] 


2 (let [storm-cluster-state (:storm-cluster-state nimbus) 

3 supervisor-infos (all-supervisor-info storm-cluster-state) 

4 33 TODO: need to get the port info about supervisors... 

5 ;; in standalone just look at metadata, otherwise just say N/A? 

6 supervisor-summaries (dofor [[id info] supervisor-infos] 

7 (let [ports (set (:meta info)) ;;only true for standalone] 

8 (SupervisorSummary. (:hostname info) 

9 (:uptime-secs info) 

10 (count ports) 

11 (count (:used-ports info)) 

12 id ) 

13 )) 

14 nimbus-uptime ((:uptime nimbus)) 

15 bases (topology-bases storm-cluster-state) 

16 topology-summaries (dofor [[id base] bases] 

17 (let [assignment (.assignment-info storm-cluster-state id nil)] 
18 (TopologySummary. id 

19 (:storm-name base) 

20 (-»» (:executor->node+port assignment) 
21 keys 

22 (mapcat executor-id-»tasks) 

23 count) 

24 (-»» (:executor->node+port assignment) 
25 keys 

26 count) 

27 (-»» (:executor->node+port assignment) 
28 vals 

29 set 

30 count) 

31 (time-delta (:launch-time-secs base)) 
32 (extract-status-str base)) 

33 2] 

34 (ClusterSummary. supervisor-summaries 

35 nimbus-uptime 

36 topology-summaries) 


37 )) 
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a 第 3 行 调用 al1-supervisor-info 获 取 <supervisor-id，SupervisorInfo> 信息 。 

O 在 第 6~13 行 中 ， 对 于 每 一 个 csupervisor-id, SupervisorInfo> 信 息 ， 首先 从 SupervisorInfo 
的 元 数据 中 获取 端口 号 信息 。 接 下 来 ,构造 SupervisorSummary 对 象 ， 其 参数 分 别 为 主机 
名 、 启 动 时 间 、 所 有 可 以 使 用 的 端口 的 数 日 、 使 用 的 端口 号 的 数目 以 及 supervisor-id。 最 
后 ， 返回 一 个 SupervisorSummary 集 合 。 

a 第 14 行 获取 Nimbus 迄 今 为 止 的 运行 时 间 。 

a 第 15 行 调用 topology-bases 获 取 所 有 Topology 的 StormBase 信 息 , 并 返回 一 个 <topology-id， 

StormBase> 集 合 。 

a 第 16~33 行 对 前 面 获 取 到 的 <topology-id，StormBase> 中 的 每 一 项 ， 首 先 根据 topology-id 
获取 其 任务 分 配 信 息 ， 然 后 构建 TopologySummary 对 象 ， 其 参数 依次 为 topology- id, 
storm-name、 所 有 的 Task 数 目 、 所 有 的 Executor 数 目 、 所 有 被 占用 的 slot 数 目 、 到 目前 为 目 
的 启动 时 间 以 及 Topology 的 当前 状态 等 。 最 终 返 回 的 将 是 一 个 TopologySummary 集 合 

a 第 34~36 行 利用 前 面 获 取 的 SupervisorSummary 集 合 、Nimbus 的 启动 时 间 eon 
集合 ， 创 建 ClusterSummary 对 象 并 返回 。 6 
2. getTopologyInfo 
该 方法 用 来 获取 一 个 Topology 的 详细 运行 情况 ， 包 括 其 topology-id、topology-name 、 从 启 
pp iiie E 所 有 Executor 的 统计 信息 、 当 前 运行 状态 以 及 运行 过 程 中 发 生 的 错误 
言 息 ， 相 关 代码 如 下 : 


1 (^TopologyInfo getTopologyInfo [this ^String storm-id] 
2 (let [storm-cluster-state (:storm-cluster-state nimbus) 
3 task-»component (storm-task-info (read-storm-topology conf storm-id) (read- 
storm-conf conf storm-id)) 
4 base (.storm-base storm-cluster-state storm-id nil) 
5 assignment (.assignment-info storm-cluster-state storm-id nil) 
6 beats (.executor-beats storm-cluster-state storm-id (:executor->node+port assignment)) 
7 all-components (-» task-»component reverse-map keys) 
8 errors (-»» all-components 
9 (map (fn [c] [c (get-errors storm-cluster-state storm-id c)])) 
1 


0 (into {})) 

11 executor-summaries (dofor [[executor [node port]] (:executor->node+port assignment) ] 
12 (let [host (-» assignment :node->host (get node)) 

13 heartbeat (get beats executor) 

14 stats (:stats heartbeat) 

15 stats (if stats 

16 (stats/thriftify-executor-stats stats))] 

17 (doto 

18 (ExecutorSummary. (thriftify-executor-id executor) 
19 (-» executor first task-»component) 

20 host 

21 port 

22 (nil-to-zero (:uptime heartbeat))) 
23 (.set stats stats)) 

24 )) 
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26 (TopologyInfo. storm-id 

27 (:storm-name base) 

28 (time-delta (:launch-time-secs base)) 
29 executor-summaries 

30 (extract-status-str base) 

31 errors 

32 ) 

33 ) 


a 第 3 行 调用 storm-task-info 方 法 获取 <task-id，component-id> 集 合 。 

a 第 4 行 根据 storm-id 获 取 该 Topology 的 StormBase 信 息 。 

O 第 5 行 根据 storm-id 获 取 该 Topology 的 Assignment 信 息 。 

口 第 6 行 根据 storm-id 和 Assignment 中 的 :executor->nodetport 信 息 获取 所 有 Executor 的 心跳 
信息 , 这 里 返回 的 是 一 个 cexecutor, (:time-secs, :uptime, :stats}>4E4, 其 中 :time-secs 
代表 Executor 对 应 的 Worker 最 后 一 次 心跳 的 更 新 时 间 ，:uptime 代 表 到 这 个 最 后 一 次 更 新 心 
跳 时 的 运行 时 间 ，:stats 则 代表 Worker 心 跳 中 记录 的 该 Executor 的 运行 统计 信息 。 

a 第 7 行 从 第 3 行 得 到 的 集合 中 获取 所 有 组 件 信息 。 

口 第 8~10 行 从 ZooKeeper 中 获取 每 一 个 组 件 产 生 的 错误 信息 。 

O 第 11~24 行 对 Assignment 中 :executor->node+port 的 每 一 项 分 别 进行 一 系列 操作 。 首 先 从 
Assignment 中 的 :node->host 信 息 获 取 主 机 信息 ， 然 后 从 第 6 行 返回 的 结果 中 根据 Executor 
获取 心跳 信息 (也 即 {:time-secs，:uptime，:stats} )， 接 下 来 从 心跳 信息 中 获取 :stats 
信息 。 如 果 运 行 统计 不 为 空 ， 调 用 stats.cj 中 的 thriftify-executor-stats 方 法 将 其 转换 为 
ExecutorStats 对 象 。 最 后 构造 ExecutorSummary 对 象 ， 并 设置 其 运行 统计 为 构造 出 的 
ExecutorStats 对 象 ， 返 回 一 个 ExecutorSummary 集 合 。 

a 第 26~32 行 创建 TopologyInfo 对 象 并 返回 ， 其 参数 有 storm-id、storm-name 、 迄 今 为 止 的 启 

动 时 间 、 前 面 返回 的 ExecutorSummary 集 合 、 当 前 Topology 状 态 以 及 所 有 出 错 信息 。 


6.7.5 获 HX Topology 


Nimbus 提 供 了 两 个 获取 Topology 的 方法 ， 其 中 getUserTopology 是 获取 用 户 提 交 的 Topology， 


返回 的 StormTopology 对 象 中 不 含有 任何 系统 组 件 (acker-bolt、metric-bolt 或 者 system-bolt ); 
getTopology 方 法 获取 真正 在 集群 上 运行 的 Topology， 返 回 的 StormTopology 对 象 中 包含 所 有 系统 
组 件 。 下 面 简要 介绍 这 两 个 方法 。 


口 getUserTopology 方 法 直接 调用 read-storm-topology 方 法 ， 根 据 topology-id 获 取 存 储 在 
Nimbus 本 地 目录 中 的 StormTopology 对 象 : 


1 (^StormTopology getUserTopology [this ^String id] 
2 (read-storm-topology conf id)) 


口 getTopology 方 法 首先 根据 topology-id 从 Nimbus 本 地 目录 中 读 取 其 对 应 的 StormTopology 
对 象 和 它 使 用 的 Storm 配 置 项 ， 然 后 调用 system-topology! 方 法 为 该 StormTopology 对 象 添 
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加 系统 组 件 ， 包 括 acker-bolt、metric-bolt 以 及 system-bolt， 最 后 返回 添加 完 这 些 组 件 
的 StormTopology 对 和 象 : 


1 (^StormTopology getTopology [this ^String id] 
2 (system-topology! (read-storm-conf conf id) (read-storm-topology conf id))) 


6.7.6 ”获取 Storm 配 置 项 


Nimbus 提 供 了 获取 Nimbus 使 用 的 Storm 配 置 项 的 方法 getNimbusConf 和 获取 某 个 Topology 使 
用 的 Storm 配 置 项 的 方法 getTopologyConf， 下 面 简 要 介绍 这 两 个 方法 。 

口 getNimbusConf 方 法 直接 返回 JSON 序 列 化 后 的 nimbus-data 中 保存 的 Nimbus 使 用 的 Storm 配 
EO. 


1 (^String getNimbusConf [this] 
2 (to-json (:conf nimbus))) 


口 getTopologyConf 方 法 调用 read-storm-conf 方 法 从 Nimbus 本 地 目录 中 读 取 该 Topology 使 用 
的 Storm 配 置 项 ， 返 回 JSON 序 列 化 该 对 象 后 的 字符 串 : 


1 (^String getTopologyConf [this ^String id] 
2 (to-json (read-storm-conf conf id))) 


6.8 主要 辅助 方法 
在 介绍 Nimbus 的 服务 方法 时 ， 我 们 提 到 了 一 些 很 重要 的 辅助 方法 ， 这 里 简单 介绍 这 些 方法 。 


6.8.1 system-topology! 


该 方法 主要 用 来 验证 用 户 提交 的 Topology， 同 时 为 用 户 提 交 的 Topology 添 加 一 些 系统 组 件 和 
流 ， 例 如 Acker、 运 行 统计 组 件 和 系统 组 件 等 。 该 方法 的 代码 如 下 : 


1 (defn system-topology! [storm-conf ^StormTopology topology] 
2 (validate-basic! topology) 

3 (let [ret (.deepCopy topology)] 

4 (add-acker! storm-conf ret) 

5 (add-metric-components! storm-conf ret) 

6 (add-system-components! storm-conf ret) 

7 (add-metric-streams! ret) 

8 (add-system-streams! ret) 

9 (validate-structure! ret) 

1 ret 

1 


)) 


a 第 2 行 调 用 validate-basic! 方 法 验证 用 户 提 交 的 Topology 是 否 符合 要 求 。 
a 第 3 行 复制 用 户 提交 的 Topology， 并 将 其 保存 到 ret 变 量 中 。 
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a 第 4 行 调用 add-acker 1! 为 ret 添 加 acker-bolt。 

a 第 5 行 调用 add-metric-components1! 为 ret 添 加 metric-bolt。 

a 第 6 行 调用 add-system-components! 为 ret 添 加 system-bolt。 

a 第 7 行 调用 add-metric-streams! 为 ret 中 的 所 有 组 件 添加 统计 流 。 

a 第 8 行 调用 add-system-streams! 为 ret 中 的 所 有 组 件 添加 系统 流 。 

a 第 9 行 调用 validate-structure! 方 法 验证 添加 完 bolt 和 流 后 的 Topology 的 正确 性 。 
a 第 10 行 返回 新 构造 的 ret 对 象 。 

下 面 我 们 会 依次 介绍 其 中 涉及 的 一 些 方法 : 

1. validate-basic! 


该 方法 负责 验证 用 户 创建 的 Topology 是 否 符合 要 求 ， 其 代码 如 下 : 


1 (defn validate-basic! [^StormTopology topology] 

2 (validate-ids! topology) 

3 (doseq [f thrift/SPOUT-FIELDS 

4 obj (-»» f (.getFieldValue topology) vals)] 

5 (if-not (empty? (-» obj .get common .get inputs)) 

6 (throw (InvalidTopologyException. "May not declare inputs for a spout")))) 
7 (doseq [[comp-id comp] (all-components topology) 

8 :let [conf (component-conf comp) 


9 p (-» comp .get common thrift/parallelism-hint)]] 

10 (when (and (» (conf TOPOLOGY-TASKS) 0) 

11 p 

12 (<= p 0)) 

13 (throw (InvalidTopologyException. "Number of executors must be greater than 0 when number of 


tasks is greater than 0")) 
14 )) 
a 第 2 行 调用 validate-ids! 方 法 确保 Topology 中 : 
u 没有 重复 的 组 件 id; 
u 组 件 id 不 是 system id ( 以 “开头 ); 
m 流 id 不 是 system id. 
口 第 3~6 行 确保 Spout 没 有 输入 。 
口 第 7~14 行 对 Topology 中 的 每 一 个 组 件 进 行 判断 ， 确 保 当 TOPOLOGY-TASKS 大 于 0 时 该 组 件 设 
置 的 并 行 度 一 定 也 大 于 0。 
2. add-acker! 
Storm PARA ck Uil oe 38 Eg ACIS HDS BA TELE e t RC LR, RT CP BIG eT Ey 
解 。Storm 默 认 提 供 了 Acker Bolt 的 实现 ， 所 以 用 户 不 需要 去 关心 这 方面 的 内 容 。add-acker! 方 法 负 
责 为 用 户 的 Topology 添 加 acker-bolt， 并 将 加 入 的 acker 与 用 户 组 件 关联 起 来 。 该 方法 的 代码 如 下 : 


1 (defn add-acker! [storm-conf ^StormTopology ret] 

2 (let [num-executors (storm-conf TOPOLOGY-ACKER-EXECUTORS) 

3 acker-bolt (thrift/mk-bolt-spec* (acker-inputs ret) 

4 (new backtype.storm.daemon.acker) 

5 (ACKER-ACK-STREAM-ID (thrift/direct-output-fields ["id"]) 
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6 ACKER-FAIL-STREAM-ID (thrift/direct-output-fields ["id"]) 

7 } 

8 :p num-executors 

9 :conf {TOPOLOGY-TASKS num-executors 

10 TOPOLOGY-TICK-TUPLE-FREQ-SECS (storm-conf TOPOLOGY-MESSAGE- 

TIMEOUT-SECS)})] 

11 (dofor [[_ bolt] (.get bolts ret) 

12 :let [common (.get common bolt)]] 

13 (do 

14 (.put to streams common ACKER-ACK-STREAM-ID (thrift/output-fields ["id" 

"ack-val"])) 

15 (.put to streams common ACKER-FAIL-STREAM-ID (thrift/output-fields ["id"])) 

16 ) 

17 (dofor [[ spout] (.get spouts ret) 

18 :let [common (.get common spout) 

19 spout-conf (merge 

20 (component-conf spout) 

21 {TOPOLOGY-TICK-TUPLE-FREQ-SECS (storm-conf 

TOPOLOGY -MESSAGE- TIMEOUT- SECS) }) ]] 

22 (do 

23 33 this set up tick tuples to cause timeouts to be triggered 

24 (.set json conf common (to-json spout-conf)) 

25 (.put to streams common ACKER-INIT-STREAM-ID (thrift/output-fields ["id" "init-val" 
"spout-task"])) 

26 (.put to inputs common 

27 (GlobalStreamId. ACKER-COMPONENT-ID ACKER-ACK-STREAM-ID) 

28 (thrift/mk-direct-grouping)) 

29 (.put to inputs common 

30 (GlobalStreamId. ACKER-COMPONENT-ID ACKER-FAIL-STREAM-ID) 

31 (thrift/mk-direct-grouping)) 

32 )) 

33 (.put to bolts ret " acker" acker-bolt) 

34  )) 


口 第 2 行 获取 用 户 设置 的 Acker Bolt 节 点 数目 。 

O 第 3~10 行 创建 并 行 度 为 Acker Bolt 数 目的 acker-bolt。 

m 第 3 行 调用 acker-inputs 方 法 获取 acker 的 所 有 输入 流 , 它 首先 从 Topology 的 polts 和 spouts 
分 别 获 取 所 有 的 bolt 的 id 列表 和 spout 的 id 列表 ， 然 后 对 于 每 一 个 spout 的 id 获取 {[id， 
ACKER-INIT-STREAM-ID] ["id"]}, 对 于 每 一 个 bolt 的 id 获 取 {[id，ACKER-ACK-STREAM-ID] 
["id"]} 和 {[id，ACKER-FAIL-STREAM-ID] ["id"]}， 最 后 将 这 两 部 分 结果 合并 作为 Acker 
Bolt 的 输入 , 它 的 结构 是 <[component-id, streamtid], Grouping-Fields>, 所 以 这 里 [id， 
ACKER-XXX-STREAM-ID] 中 的 id 即 为 component-id，ACKER-XXX-STREAM-ID 是 stream-id， 而 
[ "id"] 表 示 acker-bolt 从 这 些 流 接 收 数据 是 按照 字段 id 进行 分 组 的 。 

m 第 4 行 创建 新 的 backtype.storm.daemon.acker 对 象 。 

m 第 5~7 行 创建 acker-bolt 的 输出 ， 它 有 两 个 输出 流 一 一 ACKER-ACK-STREAM-ID 和 ACKER-FAIL- 
STREAM-ID， 这 两 个 流 的 输出 都 是 只 有 一 个 字段 it， 并且 这 两 个 流 都 为 直接 流 。 

m 第 8 行 设置 acker-bolt 的 并 行 度 。 
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m 第 9~10 行 定义 创建 acker-bolt 的 配置 参数 , 它 包 含 两 项 一 一 TOPOLOGY-TASKS 和 TOPOLOGY- 
TICK-TUPLE-FREQ-SECS, 前 者 设置 为 ackerbolt 的 并 行 度 , 后 者 设置 为 从 storm-conf 中 获取 
的 TOPOLOGY-MESSAGE-TIMEOUT-SECS。 
O 第 11~16 行 对 于 Topology 中 的 每 一 个 bolt， 为 其 中 的 ComponentCommon 对 象 的 streams 变 量 添 
加 两 个 流 : 第 一 个 是 ACKER-ACK-STREAM-ID， 设 置 它 的 字段 名 列表 是 ["id","ack-val"]， 设 
置 它 的 模式 为 非 直接 模式 : 第 二 个 是 ACKER-FAIL-STREAM-ID ， 设 置 它 的 字段 名 列表 为 是 
["id"]， 设 置 它 的 模式 是 非 直接 模式 。 
O 第 17~32 行 对 于 Topology 中 的 每 一 个 Spout， 为 其 中 的 ComponentCommon 对 象 做 以 下 操作 。 
更 新 配置 中 的 TOPOLOGY-TICK-TUPLE-FREO-SECS 为 storm-conf 中 的 TOPOLOGY-MESSAGE- 
TIMEOUT-SECS。 
m 在 streams 中 添加 ACKER-INIT-STREAM-ID ， 设 置 它 的 字段 名 列表 为 ["id" "init-val" 
"spout-task"]， 设 置 它 的 模式 为 非 直接 流 。 
m 在 输入 流 中 添加 直接 流 ack ack). 
m 在 输入 流 中 添加 直接 流 acker fail). 
a 第 33 行 将 创建 的 acker-bolt 加 入 到 Topology 中 ， 设 置 它 的 组 件 ID 为 ”acker。 
3. add-metric-components! 


该 方法 为 用 户 的 Topology 添 加 metric-bolt， 其 代码 如 下 : 


1 (defn add-metric-components! [storm-conf ^StormTopology topology] 

2 (doseq [[comp-id bolt-spec] (metrics-consumer-bolt-specs storm-conf topology)] 

3 (.put to bolts topology comp-id bolt-spec))) 

第 2~3 行 调用 metrics-consumer-bolt-specs 方 法 获取 一 个 <component-id，metric-bolt> 集 
合 ， 将 其 中 的 每 一 个 都 加 入 到 Topology 的 bolts 集 合 中 。 关 于 metric-bolt 的 详细 信息 ， 后 面 有 一 
章 专 门 介 绍 。 

4. add-system-components! 


该 方法 为 用 户 的 Topology 添 加 system-bolt， 相 关 代 码 如 下 : 


1 (defn add-system-components! [conf ^StormTopology topology] 

2 (let [system-bolt-spec (thrift/mk-bolt-spec* 

3 {} 

4 (SystemBolt.) 

5 (SYSTEM-TICK-STREAM-ID (thrift/output-fields ["rate secs"]) 

6 METRICS-TICK-STREAM-ID (thrift/output-fields ["interval"])} 
7 :po 

8 :conf {TOPOLOGY-TASKS 0})] 

9 (.put to bolts topology SYSTEM-COMPONENT-ID system-bolt-spec))) 


O 第 2~8 行 调用 mk-bolt-spec# 创 建 一 个 新 的 SystemBolt， 这 个 Bolt 没 有 输入 流 ， 输 出 流 有 两 
个 ， 一 个 是 SYSTEM-TICK-STREAM-ID， 声 明 的 字段 是 ["rate_secs"] ， 非 直接 模式 ; 另 一 个 
流 是 METRICS-TICK-STREAM-ID， 声 明 的 字段 是 ["interval"] ， 也 是 非 直接 模式 。 并 行 度 设 
置 为 0， 配 置 设置 为 TOPOLOGY-TASKS 0}。 
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口 第 9 行将 新 创建 的 System Bolt 添 加 到 Topology 的 Bolt 列 表 中 。 

5. add-metric-streams! 

该 方法 为 Topology 中 每 一 个 组 件 的 ComponentCommon 对 象 添加 统计 流 : stream-id 是 METRICS- 
STREAM-ID， 声 明 的 字段 是 ["task-info" "data-points"]， 设 置 为 非 直接 模式 ， 相 关 代码 如 下 : 


1 (defn add-metric-streams! [^StormTopology topology] 
2 (doseq [[_ component] (all-components topology) 

3 :let [common (.get common component)]] 

4 (.put to streams common METRICS-STREAM-ID 

5 (thrift/output-fields ["task-info" "data-points"])))) 


6. add-system-streams! 
该 方法 为 Topology 中 每 一 个 组 件 的 ComponentCommon 对 象 添 加 系统 流 : stream-id 是 SYSTEM- 
STREAM-ID， 声 明 的 字段 是 ["event"] ， 设 置 为 非 直接 模式 ， 相 关 代码 如 下 : 


1 (defn add-system-streams! [^StormTopology topology] 
2 (doseq [[_ component] (all-components topology) 

3 :let [common (.get common component)]] 

4 (.put to streams common SYSTEM-STREAM-ID (thrift/output-fields ["event"])))) 


T. validate-structure! 
该 方法 验证 添加 完 acker-bolt、metric-bolt 以 及 system-bolt 之 后 的 StormTopology 是 否 符 合 
要 求 ， 相 关 代 码 如 下 所 示 : 


1 (defn validate-structure! [^StormTopology topology] 
2 ;; validate all the component subscribe from component+stream which actually exists in 
the topology 


3 ;; and if it is a fields grouping, validate the corresponding field exists 
4 (let [all-components (all-components topology)] 
5 (doseq [[id comp] all-components 
6 :let [inputs (.. comp get common get inputs)]] 
7 (doseq [[global-stream-id grouping] inputs 
8 :let [source-component-id (.get componentId global-stream-id) 
9 source-stream-id (.get streamId global-stream-id)]] 
10 (if-not (contains? all-components source-component-id) 
11 (throw (InvalidTopologyException. (str "Component: [" id "] subscribes from 
non-existent component [" source-component-id "]"))) 
12 (let [source-streams (-» all-components (get source-component-id) 
.get common .get streams)] 
13 (if-not (contains? source-streams source-stream-id) 
14 (throw (InvalidTopologyException. (str "Component: [" id "] subscribes from 
non-existent stream: [" source-stream-id "] of component [" source-component-id 
"]"))) 
15 (if (= :fields (thrift/grouping-type grouping)) 
16 (let [grouping-fields (set (.get fields grouping)) 
17 source-stream-fields (-> source-streams (get source-stream-id) 
.get output fields set) 
18 diff-fields (set/difference grouping-fields source-stream-fields)] 


19 (when-not (empty? diff-fields) 
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20 (throw (InvalidTopologyException. (str "Component: [" id "] subscribes 
from stream: [" source-stream-id "] of component [" source-component-id 
"] with non-existent fields: " diff-fields))))))))))))) 
a 第 4 行 获取 Topology 中 的 所 有 组 件 ， 返 回 的 是 一 个 <component-id， 组 件 > 集 合 。 
a 第 5~20 行 对 获取 到 的 <component-id， 组 件 > 集 合 中 的 每 一 项 进行 处 理 。 

m 第 6 行 获取 组 件 的 所 有 输入 。 

u 第 7~20 行 对 输入 中 的 每 一 项 ， 获 取 它 的 source-component-id 以 及 source-stream-id。 首 
先 判断 source-component-id 是 否 在 组 件 列 表 中 ， 如 果 不 在 ， 就 抛 出 InvalidTopology 
Exception 异 常 。 如 在 则 继续 判断 source-stream-id 是 否 在 source-component-id 对 应 的 组 件 
声明 的 流 列表 中 ， 如 果 不 在 也 会 抛 出 InvalidTopologyException 异 常 ; 如 在 则 继续 检查 该 
流 的 分 组 方式 是 否 是 域 分 组 (Fields Grouping )， 如 果 是 ， 判 断 用 来 进行 分 组 的 域 是 否 都 
在 source-stream-id 对 应 的 流 中 存在 ， 如 果 不 存在 也 会 抛 出 InvalidTopologyException。 

如 果 所 有 的 component 检 查 完毕 后 都 没有 任何 异常 抛 出 ， 则 说 明 该 StormTopology 是 有 效 的 。 


6.8.2 normalize-topology 


该 方法 主要 用 于 计算 提交 的 Topology 中 每 个 组 件 的 并 行 度 并 更 新 该 组 件 的 TOPOLOGY-TASKS 配 
置 项 ， 它 的 定义 如 下 : 


1 (defn normalize-topology [storm-conf ^StormTopology topology] 

2 (let [ret (.deepCopy topology)] 

3 (doseq [[_ component] (all-components ret)] 

4 (.set json conf 

5 (.get common component) 

6 (-»» (TOPOLOGY-TASKS (component-parallelism storm-conf component) } 
7 (merge (component-conf component)) 

8 to-json ))) 

9 ret )) 


在 上 述 代 码 中 ， 输 入 参数 storm-conf 表 示 该 Topology 使 用 的 配置 项 ，topology 是 一 个 
StormTopology 对 象 ， 它 包含 了 组 成 要 提交 的 Topology 的 所 有 组 件 。 下 面 简 述 各 行 代 码 的 作用 。 

O 第 2 行 调用 StormTopology 的 deepCopy 方 法 获取 一 个 深度 拷贝 ， 这 样 做 是 因为 Clojure 是 一 个 
函数 式 编程 语言 ， 如 果 参 数 是 一 个 对 象 ， 一 般 是 不 会 修改 该 对 象 本 身 的 ， 而 是 先 复制 
份 ， 在 副本 上 做 修改 ， 最 后 返回 修改 后 的 对 象 。 

a 第 3~8 行 首先 调用 al1-components 方 法 获取 到 该 Topology 中 的 所 有 组 件 信息 ， 然 后 遍历 每 
一 个 组 件 ， 更 新 组 件 配置 中 的 ToPOLOGY-TASKS 信 息 。TOPOLOGY-TASKS 的 计算 是 通过 调用 方 
法 component-parallelism 完 成 的 。 

下 面 简单 介绍 一 下 component-parallelism 方 法 , 它 是 用 来 计算 组 件 并 行 度 的 ,相关 代码 如 下 : 


1 (defn- component-parallelism [storm-conf component] 

2 (let [storm-conf (merge storm-conf (component-conf component)) 

3 num-tasks (or (storm-conf TOPOLOGY-TASKS) (num-start-executors component)) 
4 max-parallelism (storm-conf TOPOLOGY-MAX-TASK-PARALLELISM) 
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(if max-parallelism 
(min max-parallelism num-tasks) 
num-tasks))) 


a 第 2 行 用 于 获取 配置 信息 ， 该 配置 信息 是 将 Topology 的 配置 信息 和 组 件 的 配置 信息 合并 得 

到 的 ， 如 果 二 者 有 相同 的 配置 项 ， 优 先 使 用 组 件 自己 的 配置 项 。 

O 第 3 行 计 算 num-tasks ， 也 即 该 组 件 的 并 行 度 。 如 果 第 2 行 获取 到 的 配置 项 中 设置 了 
TOPOLOGY-TASKS 信 息 ， 就 采用 该 设置 作为 num-tasks ， 否 则 通过 调用 num-start-executors 
方法 获取 用 户 为 该 组 件 设置 的 并 行 度 作 为 num-tasks。 

口 第 4 行 从 第 2 行 获 取 到 的 配置 信息 中 尝试 获取 配置 项 TOPOLOGY-MAX-TASK-PARALLELISM, 将 结 

果 保 存在 max-parallelism 中 。 

a 第 6~8 行 判断 第 4 行 是 否 获 取 到 配置 项 TOPOLOGY-MAX-TASK-PARALLELISM， 如果 获取 到 ,就 返 
回 第 3 行 计算 的 num-tasks 和 第 4 行 的 max-parallelism 中 的 较 小 值 ， 否 则 就 返回 num-tasks。 
TOPOLOGY-MAX-TASK-PARALLELISM 表 明 当 前 Topology 人 允许 并 行 运行 的 Task 的 最 大 数目 ， 这 个 
参数 主要 是 local 模 式 下 控制 线程 的 数量 ， 在 真正 的 多 机 集群 环境 中 一 般 不 会 使 用 。 

下 面 我 们 举 个 例子 来 说 明 该 计算 过 程 。 如 果 创 建 Topology 时 我 们 的 设置 如 下 : 


CON Ov un 


1  TopologyBuilder builder - new TopologyBuilder(); 

2 builder.setSpout("spouti", new Spouti(), 1); 

4 builder.setBolt("bolt", new Bolti(), 5) 

5 . shuffleGrouping("spout1") ; 

6 Config conf = new Config(); 

7 conf.setDebug(false) ; 

8  StormSubmitter.submitTopology("Test", conf, builder.createTopology()); 


对 于 组 件 bolt ， 我 们 设置 它 的 并 行 度 为 5， 没有 为 它 设置 TOPOLOGY-TASKS 以 及 TOPOLOGY- 
MAX-TASK-PARALLELISM， 所 以 对 于 该 组 件 ， 调 用 component-parallelism 方 法 的 返回 值 为 5。 
如 果 修 改 创建 过 程 ， 具 体 如 下 : 


1 TopologyBuilder builder = new TopologyBuilder(); 

2 builder.setSpout("spout1", new Spout1(), 1); 

4 builder.setBolt("bolt", new Bolt1(), 5) 

5 .ShuffleGrouping("spout1").setNumTasks(10); 

6 Config conf = new Config(); 

7 conf.setDebug(false); 

8 StormSubmitter.submitTopology("Test", conf, builder.createTopology()); 


对 于 组 件 bolt， 我 们 除了 设置 它 的 并 行 度 为 5 外 ， 还 设置 TOPOLOGY-TASKS 为 10， 没 有 为 它 设置 
TOPOLOGY-MAX-TASK-PARALLELISM, 所 以 对 于 该 组 件 ,调用 component-parallelism 方 法 的 返回 值 为 10。 
再 次 修改 创建 过 程 ， 具 体 如 下 : 


1 TopologyBuilder builder = new TopologyBuilder(); 
2 builder.setSpout("spout1", new Spout1(), 1); 
4 builder.setBolt("bolt", new Bolt1(), 5) 
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5 .ShuffleGrouping("spout1").setNumTasks(10); 

6 Config conf = new Config(); 

7 conf.setDebug(false); 

8 conf.setMaxTaskParallelism(8); 

9 StormSubmitter.submitTopology("Test", conf, builder.createTopology()); 


对 于 组 件 bolt, 我 们 除了 设置 它 的 并 行 度 为 5 外 , 还 设置 ToPOLOGY-TASKS 为 10, 设置 TOPOLOGY-MAX- 
TASK-PARALLELISM 为 8， 所 以 对 于 该 组 件 ， 调 用 component-parallelism 方 法 的 返回 值 为 8。 


6.8.3 compute-new-topology->executor->node+port 


该 方法 根据 系统 当前 已 经 存在 的 分 配 情况 (上 一 轮 分 配 后 的 结果 ), 结合 系统 当前 的 运行 情 
况 找 出 需要 进行 任务 分 配 的 Topology 集 合 ， 并 为 它们 分 配 任务 ， 计 算出 这 一 轮 分 配 完 之 后 的 每 
个 Topology 对 应 的 任务 分 配 情 况 ， 也 即 <topology-id，<executor，[node， Mibi 其 代码 
如 下 : 


1 (defn compute-new-topology->executor->node+port [nimbus existing-assignments topologies scratch- 
topology-id] 


2 (let [conf (:conf nimbus) 

3 storm-cluster-state (:storm-cluster-state nimbus) 

4 topology->executors (compute-topology->executors nimbus (keys existing-assignments)) 

5 ;; Update the executors heartbeats first. 

6 _ (update-all-heartbeats! nimbus existing-assignments topology-»executors) 

7 topology-»alive-executors (compute-topology-»alive-executors nimbus 

8 existing-assignments 

9 topologies 

10 topology-»executors 

11 scratch-topology-id) 

12 supervisor-»dead-ports (compute-supervisor-»dead-ports nimbus 

13 existing-assignments 

14 topology-»executors 

15 topology-»alive-executors) 

16 topology-»scheduler-assignment (compute-topology-»scheduler-assignment nimbus 

17 existing-assignments 

18 topology-»alive-executors) 

19 

20 missing-assignment-topologies (-»» topologies 

21 .getTopologies 

22 (map (memfn getId)) 

23 (filter (fn [t] 

24 (let [alle (get topology-»executors t) 

25 alivee (get topology-»alive-executors t)] 

26 (or (empty? alle) 

27 (not- alle alivee) 

28 (« (-» topology-»scheduler-assignment 

29 (get t) 

30 num-used-workers ) 

31 (-» topologies (.getById t) 
.getNumWorkers) 

32 )) 
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33 )))) 

34 all-scheduling-slots (->> (all-scheduling-slots nimbus topologies missing-assignment- 

topologies) 

35 (map (fn [[node-id port]] {node-id #{port}})) 

36 (apply merge-with set/union)) 

37 

38 supervisors (read-all-supervisor-details nimbus all-scheduling-slots supervisor 

->dead-ports) 

39 cluster (Cluster. (:inimbus nimbus) supervisors topology->scheduler-assignment) 

40 _(.schedule (:scheduler nimbus) topologies cluster) 

41 new-scheduler-assignments (.getAssignments cluster) 

42 ;; add more information to convert SchedulerAssignment to Assignment 

43 new-topology->executor->node+port (compute-topology->executor->node+port 

new-scheduler-assignments) 

44 supervisor-details (basic-supervisor-details-map storm-cluster-state) 

45 reassign-details (StringBuilder.)] 

46 (doseq [[topology-id executor->node+port] new-topology-»executor-»node-port 

47 :let [old-executor->node+port (-» topology-id 

48 existing-assignments 

49 :executor->node+port) 

50 reassignment (filter (fn [[executor node+port] ] 

51 (and (contains? old-executor->node+port executor) 

52 (not (= nodetport (old-executor->nodetport 

executor))))) 

53 executor->node+port) 

54 old-node->host (-> topology-id existing-assignments :node->host) 

55 new-node->host (->> executor->node+port vals (map first) set 

56 (mapcat (fn [node] 

57 (if-let [host (.getHostName (:inimbus 
nimbus) supervisor-details node) ][ [node 
host]]))) 

58 (into {}))]] 

59 (when-not (empty? reassignment) 

60 (let [new-slots-cnt (count (set (vals executor->nodet+port))) 

61 reassign-executors (keys reassignment) 

62 topology (.getById topologies topology-id)] 

63 (doseq [executor reassign-executors 

64 :let [executor-detail (ExecutorDetails. (first executor) (last executor)) 

65 old-node+port (get old-executor->node+port executor) 

66 new-node+port (get executor->node+port executor)]] 

67 (.append reassign-details 

68 (str "Executor " (get (.getExecutorToComponent topology) executor-detail) " 

" executor-detail 
69 " in topology " (.getName topology) 
70 "is reassigned from " (get old-node-»host (first old-noderport)) 
":" (second old-node-4port) 
11 "to " (get new-node-»host (first new-node+port)) ":" 
(second new-nodetport) ". "))) 

72 (log-message "Reassigning " topology-id " to " new-slots-cnt " slots") 

73 (log-message "Reassign executors: " (vec reassign-executors))))) 

74 new-topology->executor->node+port) ) 


下 面 简要 介绍 该 方法 的 几 个 参数 。 
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O nimbus: nimbus-data 对 象 。 


口 topologies: Topologies 对 象 。 


下 面 简要 介绍 上 述 代码 中 各 行 代码 的 作用 。 
口 第 2~3 行 从 nimbus-data 中 获取 :conf 和 :storm-cluster-sta 
a 第 4 行 调用 compute-topolog->executors 方 法 获取 <topolog 


口 existing-assignment: 当前 已 经 进行 的 任务 分 配 , 是 一 个 <topology-id, Assignment> 和 集合 。 


O scratch-topology-id: 当前 需要 进行 重新 分 配 操作 的 topology-id。 


te 变量 。 
y-id,executors> 集 合 (实际 上 可 


以 通过 对 每 个 topology-id 调 用 compute->executors 方 法 获取 到 ，compute->executors 方 法 


后 面 我 们 会 介绍 )。 


口 第 7~11 行 调用 compute-topology->alive-executors 获 取 
集合 。 


AssignmentImp1> 集 合 。 


口 第 6 行 调用 update-all-heartbeats! 方法 更 新 所 有 Topology 的 Executor 的 心跳 信息 。 


«topology-id,alive-executors» 


a 第 12~15 行 调用 compute-supervisor->dead-ports 获 取 <supervisor-id，dead-ports> 集 合 。 
口 第 16~18 行 调用 compute-topology->scheduler-assignment 4% HX <topology-id, Scheduler 


口 第 20~33 行 计算 missing-assignment-topologies。 首 先 获取 所 有 Topology 的 id， 然 后 按照 此 


条 件 进行 过 滤 : 该 Topology 的 所 有 Executor 为 空 或 者 该 Topology 的 所 有 Executor 不 等 于 该 
Topology 的 活跃 的 Executor 或 者 该 Topology 的 num-used-workers 小 于 其 指定 的 num-workers。 


a 第 34~36 行 计算 a1ll-scheduling-slots, 调用 all-scheduli 


SupervisorDetails> 和 集合 以 及 第 16~18 行 返回 的 <topology 
集合 创建 Cluster 对 象 。 


O 第 45 行 创建 一 个 Stringbuilder 对 象 ， 后 面 会 用 它 来 记录 


ng-slots 方 法 得 到 集合 ， 然 后 按 


照 键 进行 分 组 ， 返 回 结果 是 cnode-id( 也 即 supervisor-id)，ports2 集 合 。 
a 第 38 行 调用 read-all-supervisor-details 方 法 获取 <supervisor-id，SupervisorDetails> 集 合 。 
口 第 39 行 利用 nimbus-data 中 的 :inimbus 成 员 变 量 、 第 38 行 返回 的 <supervisor-id， 


-id, SchedulerAssignmentImpl» 


a 第 40 行 调用 nimbus-data 中 scheduler 对 象 的 schedule 方 法 来 对 当前 所 有 Topology 进 行 任 务 


口 第 41 行 从 cluster 对 象 中 获取 重新 调度 完 之 后 的 所 有 Assignments 作 为 new-schedulet- 
assignments， 它 是 一 个 <topology-id，SchedulerAssignment> 集 合 。 

a 第 43 行 调用 compute-topology->executor->nodetport 方 法 将 第 41 行 返回 的 <topology-id， 
SchedulerAssignment> 集 合 转化 为 ctopology-id，{executor [node port]}> 集 合 。 

a 第 44 行 调用 basic-supervisor-details-map 将 ZooKeeper 中 记录 的 所 有 SupervisorInfo 都 转 
化 为 SupervisorDetails， 返回 <supervisor-id， SupervisorDetails> 集 合 。 


E 新 分 配 信息 。 


O 在 第 46~73 行 中 对 于 每 一 个 Topology， 通 过 将 第 43 行 返回 的 结果 中 的 executor->node+port 与 


ZooKeeper 中 保存 的 existing-assignment 中 的 executor->node+port 信 息 进 行 对 比 ， 计 算出 重 


新 分 配 结果 reassignment (条件 是 existing-assignment 的 executor->node+port 信 息 中 包含 该 
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Executor, ， 但 是 node+port 与 新 的 executor->node+port 中 的 不 同 )。 接 下 来 ， 分 别 计算 出 
old-node->host 以 及 new-node->host， 如 果 reassignment 不 为 空 , 那么 就 会 遍历 这 些 被 重新 分 
配 的 Executor 并 打印 出 该 Executor 是 由 哪个 old-host->port 转 化 到 了 new-host->port。 

a 第 74 行 返回 第 43 行 计算 出 的 结果 ， 也 即 新 的 <topology-id，{executor [node port]}> 集 合 。 


6.8.4 compute-executors 
该 方法 主要 根据 当前 Topology 设 置 的 组 件 的 并 行 度 创建 对 应 的 Executor， 其 代码 如 下 : 


1 (defn- compute-executors [nimbus storm-id] 

2 (let [conf (:conf nimbus) 

3 storm-base (.storm-base (:storm-cluster-state nimbus) storm-id nil) 
4 component->executors (:component->executors storm-base) 
5 storm-conf (read-storm-conf conf storm-id) 

6 topology (read-storm-topology conf storm-id) 

7 task->component (storm-task-info topology storm-conf)] 
8 (storm-task-info topology storm-conf) 

reverse-map 

10 (map-val sort) 

join-maps component->executors) 


(-> 


Oo 
v 


( 
12 (map-val (partial apply partition-fixed)) 
13 (mapcat second) 
14 (map to-executor-id) 
15 )) 


该 方法 中 涉及 的 参数 如 下 所 示 。 

O nimbus: nimbus-data 对 象 。 

C) storm-id: topology-id。 

下 面 简要 介绍 各 行 代 码 的 作用 。 

口 第 3 行 获取 当前 Topology 的 StormBase 信 息 。 

a 第 4 行 从 获取 的 StormBase 信 息 中 获取 component->executors 信 息 ， 它 保存 的 是 每 个 组 件 到 

它 的 并 行 度 的 映射 。 

a 第 5 行 获取 该 Topology 对 应 的 Storm 配 置信 息 。 

口 第 6 行 获取 该 Topology 对 应 的 信息 。 

a 第 7 行 调用 storm-task-info 方 法 获取 <task-id，component-id> 集 合 。 该 方法 主要 用 于 获取 
每 个 组 件 的 TOPOLOGY-TASKS 信 息 , 并 将 其 转化 为 <ctask-id, component-id> 集 合 , 其 中 task-id 
对 该 Topology 的 所 有 组 件 来 讲 是 全 局 递增 的 。 这 里 我 们 需要 注意 ， 前 面 在 提交 Topology 时 
介绍 过 ，normalize-topology 方 法 会 计算 每 个 组 件 的 并 行 度 (依赖 于 TOPOLOGY-TASKS 的 设置 
或 是 用 户 设置 的 并 行 度 ), 并 会 将 计算 出 来 的 并 行 度 更 新 到 Storm 配 置 项 TOPOLOGY-TASKS 中 , 
所 以 这 里 获取 到 的 TOPOLOGY-TASKS 信 息 就 是 该 组 件 的 真正 运行 并 行 度 。 

口 第 8~15 行 调用 storm-task-info 方 法 获取 到 <task-id，component-id> 集 合 之 后 ， 首 先 将 集 
合 转 换 为 ccomponent-id，tasks> 集 合 ， 然 后 对 每 个 组 件 的 任务 集合 按照 升序 排序 ， 接 下 
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来 用 第 4 行 计 算出 来 的 <component-id，parallelism> 信 息 跟 排 序 后 得 到 的 <component-id， 
tasks> Æ 4 fit join #2 VF 44 | <component-id, [parallelism, tasks p ÆA, “Ja jal H 
partition-fixed 方 法 对 每 一 项 的 值 [parallelism, tasks] 进 行 处 理 , 它 主 要 是 将 这 些 tasks 
均匀 分 配 到 数目 为 parallelism 的 分 区 上 ， 返 回 parallelism 组 [task-id1 task-id2 task-id3...]fri 
息 ， 最 后 取出 这 些 信息 并 将 其 转换 为 一 组 Executor 集 合 [[start-taskId,，end-taskId] 
[start-taskId, end-taskId]...]， 其 中 每 个 Executor 集 合 都 由 一 组 连续 的 Task 组 成 ， 所 以 
Executor 的 表示 方式 为 开始 Task 的 TaskId 和 结束 Task 的 TaskId。 如 果 用 户 没 有 为 每 一 个 组 件 
单独 设置 Task 数 目 ， 那 么 组 件 的 Task 数 目 跟 parallelism 数 目 是 相等 的 ， 这 也 意味 着 每 个 
Executor 实 际 上 只 有 一 个 Task， 也 即 start-taskId=end-taskId。 


Scheduler 


Scheduler 是 Storm 的 调度 器 ， 它 负责 为 Topology 分 配 当 前 集群 中 可 用 的 资源 。Storm 定 义 了 
IScheduler 接 口 ， 用 户 可 以 通过 实现 该 接口 来 定义 自己 的 Scheduler。Storm 提 供 了 3 种 Scheduler 一 一 
EvenScheduler DefaultSchedulerfllIsolationScheduler, ， 下 面 简要 介绍 一 下 它们 。 

O EvenScheduler: 会 将 系统 中 的 可 用 资源 均匀 地 分 配给 当前 需要 任务 分 配 的 多 个 Topology。 
口 DefaultScheduler: 跟 EvenScheduler 基 本 一 致 ， 唯 一 的 区 别 在 于 它 会 在 为 Topology 分 配 任 
务 之 前 先 释 放 掉 其 他 Topology 不 再 需要 的 资源 ， 然 后 调用 EventScheduler 方 法 为 Topology 
均匀 分 配 资源 。 
口 IsolationScheduler: 它 提供 了 一 种 机 制 ， 使 得 用 户 可 以 单独 为 某 些 Topology 指 定 它们 需 
要 的 机 器 资源 (机 器 数目 )。 用 户 需 要 在 Storm 配 置 项 中 指定 这 些 信息 (topology-name 及 
其 所 需 的 机 器 数目 ), IsolationScheduler 会 优先 对 这 些 Topology 分 配 任务 , 保证 分 配给 某 
个 Topology 的 机 器 只 4 能 运行 这 个 特定 的 Topology， 相 当 于 这 些 Topology 的 运行 环境 是 相互 
独立 的 。 待 这 些 指定 的 Topology 分 配 完 成 之 后 ， 再 调用 Defaultscheduler ， 利 用 系统 中 剩 
余 的 资源 为 剩余 的 Topology 进 行 任务 分 配 。 


7.1 IScheduler 接口 


该 接口 是 Storm 定 义 的 为 集群 当前 所 有 Topology 分 配 任务 的 接口 ， 用 户 可 以 基于 该 接口 实现 
定义 的 Scheduler， 它 的 定义 如 下 : 


public interface IScheduler ( 


void prepare(Map conf); 


* Set assignments for the topologies which needs scheduling. The new assignments is available 


1 

2 

3 

4 

5 ER 

6 

7 * through «code»cluster.getAssignments()«/code» 

8 * 

9 *@param topologies all the topologies in the cluster, some of them need schedule. Topologies 
object here 

10  *only contain static information about topologies. Information like assignments, 

slots are all in 


11 *the «code»cluster«/code»object. 
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12 *@param cluster the cluster these topologies are running in. <code>cluster</code> contains 
everything user 

13 *need to develop a new scheduling logic. e.g. supervisors information, available slots, 
current 

14 *assignments for all the topologies etc. User can set the new assignment for topologies using 

15 *«code»cluster.setAssignmentById«/code» 


16 17 
17 void schedule(Topologies topologies, Cluster cluster); 
18 } 


这 个 定义 中 ， 主 要 涉及 两 个 方法 ， 有 具体 如 下 所 示 。 

O prepare 方 法 : 它 接收 当前 Nimbus 的 Storm 配 置 作为 参数 ， 以 进行 一 些 初始 化 工作 。 

口 scheduler 方 法 : 它 是 真正 进行 任务 分 配 的 方法 。 在 Nimbus 进 行 任务 分 配 的 时 候 会 调用 该 
方法 。 它 的 参数 包括 topologies 和 cluster: 前 者 含有 了 当前 集群 中 所 有 的 Topology 信 息 ， 
后 者 则 代表 当前 集群 ， 其 中 包含 用 户 自 定义 调度 逻辑 时 所 需 的 所 有 资源 ， 包 括 Supervisor 
信息 、 当 前 可 用 的 所 有 slot， 以 及 任务 分 配 情况 等 。 


7.2  EvenScheduler 


EvenSchedulez 是 一 个 对 资源 进行 均匀 分 配 的 调度 器 , 它 实现 了 IScheduler 接 口 , 相关 代码 如 下 : 


1 (defn -prepare [this conf] 

2 ) 

3 

4 (defn -schedule [this ^Topologies topologies ^Cluster cluster] 
5 (schedule-topologies-evenly topologies cluster)) 


可 以 看 到 ，Evenscheduler 是 通过 调用 schedule-topologies-evenly 方 法 来 完成 任务 分 配 的 ， 
下 面 我 们 就 来 介绍 这 个 方法 以 及 它 所 调用 的 几 个 方法 。 


7.2.1 schedule-topolpgies-evenly 
该 方法 会 均匀 地 为 Topology 分 配 系 统 当前 的 资源 ， 相 关 代码 如 下 : 


1 (defn schedule-topologies-evenly [^Topologies topologies ^Cluster cluster] 

2 (let [needs-scheduling-topologies (.needsSchedulingTopologies cluster topologies)] 
3 (doseq [^TopologyDetails topology needs-scheduling-topologies 

4 :let [topology-id (.getId topology) 

5 new-assignment (schedule-topology topology cluster) 

6 noderport-»executors (reverse-map new-assignment)]] 

7 (doseq [[node+port executors] node+port->executors 

8 :let [^WorkerSlot slot (WorkerSlot. (first nodetport) (last node+port)) 
9 executors (for [[start-task end-task] executors] 

10 (ExecutorDetails. start-task end-task))]] 

11 (.assign cluster slot topology-id executors))))) 


它 的 输入 参数 topologies 和 cluster 前 面 已 介绍 过 , RENEE, 下 面 简 要 介绍 各 行 代 码 的 
作用 。 
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a 第 2 行 通 过 调用 cluster 对 象 的 needsSchedulingTopologies 方 法 来 获取 所 有 需要 进行 任务 
调度 的 Topology 集 合 。 这 里 , 判断 Topology 是 否 需 要 进行 任务 调度 的 依据 有 两 个 : Topology 
设置 的 NumWorkers 数 目 是 否 大 于 已 经 分 配给 该 Topology 的 Worker 数 目 ， 以 及 该 Topology 尚 
未 分 配 的 Executor 的 数目 是 否 大 于 0。 

口 第 3~6 行 对 需要 进行 任务 调度 的 Topology 中 的 每 一 个 ,首先 获 取 其 topology-id, 然后 调用 
schedule-topology 方 法 ( 后面 会 介绍 ) 获取 计算 得 到 的 new-assignment ( «executor, 
node+port> 和 集合 ), 最 后 将 new-assignment 的 键 和 值 颠倒 获取 <node+port，executors> 集 合 。 

O 第 7~11 行 对 于 前 面 获 取 的 <node+port，executors> 集 合 中 的 每 一 项 进行 以 下 操作 。 

口 第 8 行 用 node 和 port 信 息 构造 WorkerSlot 对 象 并 将 其 作为 slot。 

O 第 9~10 行 对 于 Executor 集 合 中 的 每 一 项 ， 构 造 ExecutorDetail 对 象 ， 并 返回 一 个 Executor 

Details 集 合作 为 executors。 

口 第 11 行 调用 cluster 的 assign 方 法 将 计算 出 来 的 slot 分 配给 与 该 Topology 相 对 应 的 
executors ( 第 9~10 行 的 计算 结果 )。 


7.2.2 schedule-topology 
该 方法 会 根据 集群 当前 的 可 用 资源 对 Topology 进 行 任务 分 配 ， 其 代码 如 下 : 


1 (defn- schedule-topology [^TopologyDetails topology ^Cluster cluster] 

2 (let [topology-id (.getId topology) 

3 available-slots (-»» (.getAvailableSlots cluster) 

4 (map #(vector (.getNodeId %) (.getPort %)))) 

5 all-executors (-»» topology 

6 .getExecutors 

7 (map #(vector (.getStartTask %) (.getEndTask %))) 

8 set) 

9 alive-assigned (get-alive-assigned-node+port->executors cluster topology-id) 

10 total-slots-to-use (min (.getNumWorkers topology) 

11 (+ (count available-slots) (count alive-assigned))) 

12 reassign-slots (take (- total-slots-to-use (count alive-assigned)) 

13 (sort-slots available-slots)) 

14 reassign-executors (sort (set/difference all-executors (set (apply concat (vals 
alive-assigned))))) 

15 reassignment (into {} 

16 (map vector 

17 reassign-executors 

18 33 for some reason it goes into infinite loop without limiting the repeat-seq 

19 (repeat-seq (count reassign-executors) reassign-slots)))] 

20 (when-not (empty? reassignment) 

21 (log-message "Available slots: " (pr-str available-slots)) 

22 

23 reassignment)) 


a 第 2 行 获取 topology-id。 
a 第 3~4 行 调用 cluster 的 getAvailableSlots 方 法 获取 集群 当前 可 用 的 slot 资 源 ， 并 将 其 转换 
为 <node, port> 集 合 赋 给 availabple-slots 变 量 。getAvailableSlots 方 法 主要 负责 计算 出 当 
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前 集群 中 还 没有 使 用 的 Supervisor 端 口 。 

口 第 5~8 行 将 Topology 中 的 ExecutorDetails 集 合 转换 为 <start-task-id，end-task-id> 集 合 ， 

然后 赋 给 all-executors 并 返回 。 

口 第 9 行 调 用 get-alive-assigned-node+port->executors 方 法 计算 当前 该 Topology 已 经 分 得 
的 资源 情况 ， 最 后 返回 一 个 cnode+port，executors> 集 合并 将 其 保存 到 alive-assigned 变 

量 中 。 

a 第 10~11 行 计算 当前 Topology 可 以 使 用 的 slot 数 目 ， 将 其 作为 total-slots-to-use 变 量 的 内 
容 。 该 值 取 以 下 两 者 中 的 最 小 值 。 

m Topology 设 置 的 Worker 数 日 ; 
u 当前 的 available-slots 数 目 加 上 alive-assigned 数 目 。 

a 第 12~13 行 对 available-slots 进 行 排序 (这 个 排序 方法 会 在 后 面 介 绍 )， 计 算 需 要 分 配 的 
slot 数目 ( total-slots-to-use 减 去 alive-assigned 的 数目 )， 最 后 从 排序 后 的 
available-slots 集 合 中 按 顺 序 取出 这 些 slot 作 为 reassign-slots。 

a 第 14 行 通过 比较 all-executors 跟 已 经 分 配 的 Executor 集 合 间 的 差异 , 获取 需要 进行 分 配 的 

Executor 集 合 ， 并 将 其 作为 reassign-executors。 

a 第 15~19 行 将 前 面 计 算出 来 的 reassign-executors 和 reassign-slots 进 行 关 联 ， 转 换 为 
xexecutor，slot> 映 射 集合 ， 并 保存 在 reassignment 中 ， 这 时 有 两 种 情况 。 
reassign-executors 数 目 少 于 reassign-slots 数 日 。 这 意味 着 当前 集群 中 的 可 用 资源 比 

fi. 比如 reassign-executors 是 {e1,e2,e3}, 而 reassign-slots 是 {slot1, slot2,slot3， 
slot4,slot5}， 那 么 就 只 取 reassign-slots 的 前 三 项 跟 reassign-executors 配 对 ， 返 回 
{[e1,slot1],[e2, slot2], [e3, slot3]}。 
reassign-executors 数 目 大 于 reassign-slots 数 日 ， 这 意味 着 当前 集群 中 的 可 用 资源 非 

常 有 限 。 比 如 reassign-executors 是 {e1,e2,e3,e4,e5,e6}， 而 reassign-slots 是 {slot1， 
slot2), ， 此 时 就 会 有 多 个 Executor 被 分 配 到 同一 个 slot 上 ， 返 回 的 结果 则 可 能 是 
{[e1,slot1],[e2,slot2],[e3,slot1],[e4,slot2],[e5,slot1],[e6,slot2]}. 

a 第 20~22 行 判断 reassignment 是 否 为 空 ， 若 不 为 空 则 打印 日 志 记录 当前 可 用 的 slot 信 息 。 

a 第 23 行 返回 计算 得 到 的 reassignment， 它 是 一 个 cexecutor，[node，port]> 集 合 。 


S 


.3 get-alive-assigned-node+port->executors 


这 个 方法 用 于 获取 Topology 当 前 已 经 分 得 的 资源 ， 其 代码 如 下 : 


1 (defn get-alive-assigned-node+port->executors [cluster topology-id] 

2 (let [existing-assignment (.getAssignmentById cluster topology-id) 

3 executor->slot (if existing-assignment 

4 (.getExecutorToSlot existing-assignment) 

5 {}) 

6 executor->node+port (into {} (for [[^ExecutorDetails executor ^WorkerSlot slot] 
executor->slot 
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7 :let [executor [(.getStartTask executor) (.getEndTask executor)] 
8 node+port [(.getNodeId slot) (.getPort slot)]]] 

9 {executor noderport])) 

10 alive-assigned (reverse-map executor->node+port) ] 

11 alive-assigned)) 


a 第 2 行 获取 该 Topology 当 前 的 assignment。 

a 第 3~5$ 行 判断 当前 的 assignment 是 否 为 空 , 若 不 为 空 , 则 获取 其 中 的 <executor，slot> 信 息 。 
a 第 6~9 行 将 前 面 取得 的 <executor，slot> 信 息 转 换 为 <executor，[node,port]> 集 合 。 

a 第 10 行 将 前 面 的 cexecutor，[node，port]> 信 息 转 换 为 <[node，port]，executors> 信 息 。 
a 第 11 行 返回 算出 的 <[node，port]，executors> 信 息 。 


7.2.4 sort-slots 
该 方法 会 对 slot 进 行 排 序 ， 其 代码 如 下 : 


1 (defn sort-slots [all-slots] 

2 (let [split-up (vals (group-by first all-slots))] 
3 (apply interleave-all split-up) 

4 

5 

6 (defn interleave-all [& colls] 

7 (if (empty? colls) 

8 

9 (let [colls (filter (complement empty?) colls) 
10 my-elems (map first colls) 

11 rest-elems (apply interleave-all (map rest colls))] 
12 (concat my-elems rest-elems) 

13. )) 


该 方法 的 参数 是 需要 进行 排序 的 slot 列 表 ， 下 面 简要 介绍 各 行 代 码 的 作用 。 

a 第 2 行将 所 有 的 slot 按 照 键 ( 也 即 supervisor-id ) 进行 分 组 ， 然 后 返回 分 组 之 后 的 值 的 
集合 。 

a 第 3 行 调用 interleave-al1 方 法 对 前 面 返回 的 集合 进行 处 理 。 

O 第 6 行 定义 了 interleave-all 方 法 。 

a 第 7 行 判 断 传 入 的 col1s 集 合 是 否 为 空 ， 如 果 为 空 ， 直 接 返 回 空 集合 。 

a 第 9 行 过滤 掉 传人 集合 中 的 空 元 素 。 

口 第 10 行 调用 map first 处 理 传人 的 coll1s 集 合 。map 人 first 会 遍历 colls 集 合 ， 获 取 其 中 每 个 
集合 的 第 一 个 元 素 ， 并 将 返回 的 结果 保存 在 my-elems 中 。 

a 第 11 行 递归 调用 interleave-al1 处 理 剩 下 的 集合 。 

O 第 12 行将 第 10 行 和 第 11 行 的 处 理 结果 合并 成 一 个 集合 返回 。 

1. sort-slots 示 例 

下 面 我 们 来 举例 介绍 这 个 sort-slots 方 法 的 执行 过 程 。 

假设 我 们 传人 的 slot 集 合 为 (fa” 1] [“b” 1] [*e" 1] [a 2] [“b”2] [*c" 2] [*a" 3] [“b” 3] [“c” 3])， 
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经 过 第 2 行 处 理 后 返回 的 结果 是 ([[“a”1] [*a" 2] [*a" 3]] [[*b" 1] [b 2] [“b” 3]] [[*c" 1] [e" 2] 
[“c”3]])。 然 后 调用 interleave-all 继 续 对 其 进行 处 理 , 第 10 行 返回 的 my-elems 将 是 ([“a”1][“b”1] 
[“c”1])。 第 11 行 递归 调用 传人 的 参数 是 ([[“a”2] [“a”3]] [[“b 2”] [“b”3]] [[“c”2] [“c”3]])， 返 回 的 
rest-elems 是 ([“a”2] [“b”2] [*c" 2] [“a” 3] [“b”3] [“c”3])。 所 以 最 终 返 回 的 结果 是 ([“a” 1] [“b”1] 
[^e 1] [“a” 2] [“b” 2] [“c” 2] a 3] [“b” 3] he sa 

2. sort-slots 方 法 的 问题 

这 个 排序 方法 看 上 去 好 像 是 均匀 分 布 的， 但 在 实际 应 用 中 却 可 能 导致 集群 中 资源 分 配 不 均 
名， 即 出 现 有 的 机 右上 所 有 的 slot 都 被 占用 但 是 有 的 机 器 上 的 slot 却 一 个 也 没 被 占用 的 现象 。 

从 上 面 对 sort-slots 方 法 的 介绍 中 也 能 很 好 地 理解 这 一 点 。 还 是 上 面 的 这 个 例子 ， 若 
Topology1 提 交 的 时 候 ， 当 前 集群 中 的 资源 都 是 空闲 的 ， 排 序 后 返回 的 就 是 ([“a” 1] [*b" 1] [*c" 1] 
[^a" 2] [*b" 2] [*c" 2] [*a" 3] [“b” 3] [“c”3])。 假 设 Topology1 需 要 使 用 2 个 slot， 分 配 完 之 后 [“a”1]] 
和 [“b>”1] 就 已 经 被 占用 了 ， 此 时 我 们 提交 Topology2， 再 次 排序 返回 的 结果 将 是 ([“a” 2] [“b” 2] [e 
1] [“a” 3] [“b” 3] [*c" 2] [“ 3])， 这 时 如 果 Topology2 需 要 4 个 slot， 它 就 会 使 用 ([“a” 2] [“b”2] [*e" 1] 
[“a”3])。 这 样 ， 系 统 中 的 分 配 情况 便 是 机 器 a 上 的 三 个 slot 都 被 用 完了 ， 机 了 嚣 b 上 用 掉 了 两 个 slot， 
而 机 器 c 上 仅 使 用 了 一 个 。 我 们 期 望 的 情形 却 是 均匀 分 配 ( 暂 不 考虑 CPU 和 内 存 )， 也 即 a、b c 
机 器 上 都 有 两 个 slot 被 占用 。 如 何 做 到 这 一 点 呢 ?” 其 实 只 要 稍微 改 一 下 排序 的 算法 , 换 为 按照 slot 
的 port 进 行 排序 和 分 组 ， 然 后 对 每 个 分 组 内 部 分 别 进行 排序 ( 这 一 步 可 有 可 无 ) 即 可 。 


7.3 DefaultScheduler 


DefaultSchedulez 是 Storm 默 认 的 任务 调度 器 ， 如 果 用 户 没有 指定 自己 实现 的 调度 器 ，Storm 
就 会 使 用 该 调度 器 进行 任务 分 配 。 其 实现 如 下 : 


1 (defn -prepare [this conf] 

2 

3 

4 (defn -schedule [this ^Topologies topologies ^Cluster cluster] 
5 (default-schedule topologies cluster)) 


它 的 schedule 方 法 会 调用 default-schedule 方 法 来 进行 任务 分 配 。 下 面 我 们 详细 介绍 一 下 这 
个 方法 以 及 它 所 依赖 的 几 个 主要 方法 。 


7.3.1 default-schedule 


这 个 方法 主要 是 计算 当前 集群 中 所 有 可 供 分 配 的 slot 资 源 , 并 判断 当前 已 经 分 配给 该 Toplolgy 
的 slot 资 源 是 否 需要 重新 分 配 ， 然 后 通过 这 些 信息 明 确 哪 些 slot 可 被 用 来 对 新 提交 的 Topology 进 行 
任务 分 配 ， 最 后 调用 EvenScheduler 的 schedule-topologies-evenly 方 法 完成 分 配 。 其 代码 如 下 : 


1 (defn default-schedule [^Topologies topologies ^Cluster cluster] 
2 (let [needs-scheduling-topologies (.needsSchedulingTopologies cluster topologies)] 
3 (doseq [^TopologyDetails topology needs-scheduling-topologies 
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4 :let [topology-id (.getId topology) 
5 available-slots (-»» (.getAvailableSlots cluster) 
6 (map #(vector (.getNodeId %) (.getPort %)))) 
7 all-executors (-»» topology 
8 -getExecutors 
9 (map #(vector (.getStartTask %) (.getEndTask %))) 
10 set) 
11 alive-assigned (EvenScheduler/get-alive-assigned-node+port 
->executors cluster topology-id) 
12 can-reassign-slots (slots-can-reassign cluster (keys alive-assigned) ) 
13 total-slots-to-use (min (.getNumWorkers topology) 
14 (+ (count can-reassign-slots) (count available-slots))) 
15 bad-slots (if (> total-slots-to-use (count alive-assigned) ) 
16 (bad-slots alive-assigned (count all-executors) total-slots-to-use) 
17 [01] 
18 (.freeSlots cluster bad-slots) 
19 (EvenScheduler/schedule-topologies-evenly (Topologies. {topology-id topology}) 
cluster)))) 


口 第 2 行 调用 cluster 的 needsSchedulingTopologies 方 法 获取 所 有 需要 进行 任务 调度 的 

Topology 集 合 ， 详 见 前 面 有 关 EvenScheduler 的 介绍 。 

口 第 3~19 行 是 对 每 一 个 需要 进行 任务 调度 的 Topology 进 行 处 理 

口 第 4 行 获取 topology-id。 

a 第 5~6 行 调用 cluster 的 getAvailableSlots 方 法 获取 当前 集群 中 所 有 可 用 的 slot 资 源 ， 并 将 

其 转换 为 cnode，port> 集 合 赋 给 availabple-slots 变 量 。 

口 第 7~10 行 获取 Topology 的 所 有 的 Executor 信 息 ， 并 将 其 转换 为 <start-task-id,end-task- 

id> 集 合 存 人 al1-executors。 

a 第 11 行 调用 EvenScheduler 的 get-alive-assigned-node+port->executors 方 法 ， 计 算 当 前 
Topology 已 经 分 得 的 任务 信息 ， 将 返回 的 <[node,port]，executor> 信息 保 存 到 
alive-assigned 变 量 中 。 

a 第 12 行 调用 slots-can-reassign 方 法 对 alive-assigned 的 slot 信 息 进 行 判 断 , 选 出 其 中 可 被 
重新 分 配 的 slot 集 合并 保存 到 can-reassign-slots 变量 中 。 后 面 我 们 会 介绍 
slots-can-reassign 方 法 的 具体 实现 。 

a 第 13~14 行 计算 当前 Topology 所 能 使 用 的 全 部 slot 的 数目 , 它 取 以 下 两 个 量 中 较 小 的 值 作为 
total-slots-to-use。 

m Topology 的 NumWorkers 参 数值 。 
m available-slots 的 数目 加 上 can-reassign-slots 的 数目 。 

口 第 15~17 行 用 于 判断 如 果 total-slots-to-use 的 数 日 大 于 当前 已 经 分 配 的 slot 数 日 ， 则 调用 

bad-slots 方 法 计算 所 有 可 被 释放 的 slot。 后 面 我 们 会 介绍 bad-slots 这 个 方法 。 

口 第 18 行 调用 cluster 的 freeSlots 方 法 释放 前 面 计 算出 来 的 bad-slots。 

a 第 19 行 调用 EvenSscheduler 的 schedule-topologies-evenly 方 法 将 系统 中 的 资源 均匀 分 配 

该 Topology。 


o 
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7.3.2 slots-can-reassign 


这 个 方法 从 已 经 分 配给 当前 Topology 的 资源 中 过 滤 出 可 以 继续 使 用 的 资源 ， 其 代码 如 下 : 


1 (defn slots-can-reassign [^Cluster cluster slots] 

2 (-»» slots 

3 (filter 

4 (fn [[node port]] 

5 (if-not (.isBlackListed cluster node) 

6 (if-let [supervisor (.getSupervisorById cluster node)] 
7 (.contains (.getAllPorts supervisor) (int port)) 

8 


0)» 

该 方法 的 输入 参数 有 两 个 。 
O cluster: cluster 对象， 前 面 我 们 介绍 过 。 
口 slots: 已 经 分 配 的 Slot 资源， 是 一 个 cnode，port> 集 合 。 

该 方法 将 对 传人 的 slots 集 合 进行 过 泪 ， 选 出 其 中 仍然 可 以 继续 使 用 的 slot 组 成 新 的 集合 。 
过 波 方 法 是 先 判断 slot 的 node 信 息 是 否 存在 于 集群 的 黑 名 单 里 。 如 果 不 在 ， 继 续 判 断 slot 的 port 
信息 是 否 在 与 node 相 对 应 的 Supervisor 的 所 有 可 用 端口 列表 中 ， 如 果 在 ， 那 么 这 个 slot 就 可 以 继 
续 使 用 。 


7.3.3 bad-slots 
这 个 方法 用 于 计算 一 个 Topology 已 经 被 分 配 的 资源 中 哪些 是 不 再 需要 的 ， 其 代码 如 下 : 


1 (defn- bad-slots [existing-slots num-executors num-workers] 

2 (if (= 0 num-workers) 

3 ' 

4 (let [distribution (atom (integer-divided num-executors num-workers)) 

5 keepers (atom {})] 

6 (doseq [[node+port executor-list] existing-slots :let [executor-count 
(count executor-list)]] 

7 (when (pos? (get Gdistribution executor-count 0)) 

8 (swap! keepers assoc nodetport executor-list) 

9 (swap! distribution update-in [executor-count] dec) 

10 

11 (->> @keepers 

12 keys 

13 (apply dissoc existing-slots) 

14 keys 

15 (map (fn [[node port]] 

16 (WorkerSlot. node port))))))) 


首先 介绍 该 方法 的 参数 。 

口 existing-slots: 已 经 分 配给 Topology 的 资源 ， 它 是 一 个 <[node,，port],，executors> 集 合 。 
O num-executors: Topology 的 所 有 Executor (包括 已 经 分 配 的 和 未 分 配 的 )。 

口 num-workers: Topology 可 使 用 的 全 部 slot 数 目 。 
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下 面 简要 介绍 各 行 代码 的 作用 。 
a 第 2 行 判 断 num-workers 是 否 为 0。 如 果 是 ， 表 明 当 前 没有 可 供 该 Topology 使 用 的 slot， 这 时 
返回 一 个 空 集合 。 

口 第 4~5 行 定义 distribution 集 合 和 keepers 集 合 。distribution 集 合 通 过 调用 integer- 
divided 方 法 生成 ， 它 实际 上 就 是 将 num-executors 均 匀 地 分 配 到 num-workers 中 。 例 如， 若 
num-executors 是 10，num-workers 是 4， 这 时 计算 出 来 的 结果 将 是 一 个 <executor-count， 
worker-count> 集 合 ( 这 个 例子 中 是 {<2,2>,<3,2>} )。executor-count 代 表 某 个 worker 被 分 
配 了 多 少 个 Executor，worker-count 则 代表 有 多 少 个 这 样 的 Worker。 所 以 对 于 这 个 例子 ， 
计算 结果 表明 有 2 个 Worker 上 会 被 分 别 分 配 2 个 Executor，2 个 Worker 上 会 被 分 别 分 配 3 个 
Executor。keepers 集 合 默认 为 空 集合 。 

口 第 6~10 行 对 于 传人 的 existing-slots 中 的 每 一 项 ， 计 算 其 对 象 的 executor-count ， 然 后 从 
前 面 计 算 的 distribution 集 合 中 以 该 executor-count 作 为 键 去 获取 值 。 如 果 获 取 的 值 大 于 
0， 意 味 着 存在 这 样 的 分 配 ,， 也 即 存在 至 少 一 个 Worker 上 有 executor-count 个 Executor, Jf 
么 ， 当 前 这 个 分 配 信息 便 会 继续 维持 。 这 时 ， 会 将 该 <[node，port]， executors> 信 息 放 
入 keepers 中 ， 同 时 将 distribution 中 该 executor-count 的 对 应 值 减 一 。 

口 第 11~16 行 从 existing-slots 中 移 除 keepers 中 记录 的 需要 继续 维持 的 分 配 情况 .如果 移 除 完 之 
后 还 存在 slot 信 息 ， 表 明 这 些 slot 可 以 被 释放 掉 ， 于 是 将 其 转换 为 WorkerSslot 对 象 集合 并 返回 。 
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这 是 Storm 本 身 提供 的 男 外 一 种 调度 器， 它 的 主要 目的 是 提供 一 种 机 制 来 确保 集群 中 的 某 些 


Topology 有 足够 的 运行 资源 。 要 使 用 这 个 调度 带 ， 需 要 在 配置 项 中 给 定 isolation.scheduler. 
machines 参 数 ， 其 内 容 是 一 个 从 Topology 的 名 字 到 指定 机 器 数目 的 映射 ， 另 外 还 需要 将 
storm.scheduler 设 置 为 backtype.storm.scheduler.IsolationSscheduler。 下 面 我 们 来 介绍 它 的 实 


现 , 


其 代码 如 下 : 


(defn -prepare [this conf] 
(container-set! (.state this) conf)) 


1 

2 

3 

4 (defn -schedule [this ^Topologies topologies ^Cluster cluster] 

5 (let [conf (container-get (.state this)) 

6 orig-blacklist (HashSet. (.getBlacklistedHosts cluster)) 

7 iso-topologies (isolated-topologies conf (.getTopologies topologies)) 

8 iso-ids-set (-»» iso-topologies (map #(.getId ^TopologyDetails %)) set) 


9 topology-worker-specs (topology-worker-specs iso-topologies) 

10 topology-machine-distribution (topology-machine-distribution conf iso-topologies) 
11 host-assignments (host-assignments cluster)] 

12 (doseq [[host assignments] host-assignments] 

13 (let [top-id (-» assignments first second) 

14 distribution (get topology-machine-distribution top-id) 

15 ^Set worker-specs (get topology-worker-specs top-id) 

16 num-workers (count assignments) 
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18 (if (and (contains? iso-ids-set top-id) 

19 (every? #(= (second %) top-id) assignments) 

20 (contains? distribution num-workers) 

21 (every? #(contains? worker-specs (nth % 2)) assignments)) 

22 (do (decrement-distribution! distribution num-workers) 

23 (doseq [[_ _ executors] assignments] (.remove worker-specs executors) ) 

24 (.blacklistHost cluster host) ) 

25 (doseq [[slot top-id _] assignments] 

26 (when (contains? iso-ids-set top-id) 

27 (.freeSlot cluster slot) 

28 )) 

29 ))) 

30 

31 (let [host->used-slots (host->used-slots cluster) 

32 ^LinkedList sorted-assignable-hosts (host-assignable-slots cluster)] 

33 ;; TODO: can improve things further by ordering topologies in terms of who needs the 

least workers 

34 (doseq [[top-id worker-specs] topology-worker-specs 

35 :let [amts (distribution->sorted-amts (get topology-machine-distribution 
top-id))]] 

36 (doseq [amt amts 

37 :let [[host host-slots] (.peek sorted-assignable-hosts)]] 

38 (when (and host-slots (»- (count host-slots) amt)) 

39 (.poll sorted-assignable-hosts) 

40 (.freeSlots cluster (get host-»used-slots host)) 

41 (doseq [slot (take amt host-slots) 

42 :let [executors-set (remove-elem-from-set! worker-specs)]] 

43 (.assign cluster slot top-id executors-set)) 

44 (.blacklistHost cluster host)) 

45 ))) 

46 

47 (let [failed-iso-topologies (->> topology-worker-specs 

48 (mapcat (fn [[top-id worker-specs] ] 

49 (if-not (empty? worker-specs) [top-id]) 

50 )))] 

51 (if (empty? failed-iso-topologies) 

52 ;; run default scheduler on non-isolated topologies 

53 (-«» topology-worker-specs 

54 allocated-topologies 

55 (leftover-topologies topologies <>) 

56 (DefaultScheduler/default-schedule <> cluster)) 

57 (do 

58 (log-warn "Unable to isolate topologies " (pr-str failed-iso-topologies) ". 
No machine had enough worker slots to run the remaining workers for these 
topologies. Clearing all other resources and will wait for enough resources 
for isolated topologies before allocating any other resources.") 

59 33 Clear workers off all hosts that are not blacklisted 

60 (doseq [[host slots] (host->used-slots cluster) ] 

61 (if-not (.isBlacklistedHost cluster host) 

62 (.freeSlots cluster slots) 

63 ))) 

64 

65 (.setBlacklistedHosts cluster orig-blacklist) 

66 )) 
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a 第 2 行 调用 container-set! 方 法 将 Storm 配 置 项 信息 保存 到 state 中 。 

口 第 5 行 获取 state 中 保存 的 Storm 配 置 项 。 

a 第 6 行 获取 调度 前 cluster 对 象 保存 的 主机 名 的 黑 名 单 集合 。 由 于 在 调度 的 执行 过 程 中 会 对 

该 集合 进行 修改 ， 因 此 这 里 需 提前 保存 原始 值 ， 待 调度 完成 后 再 将 它 恢复 原 值 。 

a 第 7 行 调用 isolated-topologies 方 法 获取 传人 的 Topologies 对 象 中 需要 单独 分 配 资源 的 
Topology 信 息 。 至 于 哪些 Topology 需 要 进行 单独 分 配 ， 则 由 前 面 提 到 的 isolation. 
scheduler .machines 参 数 来 指定 。isolated-topologies 返 回 的 是 一 个 Topology Details 集 
合 ， 该 集合 会 被 保存 到 iso-topologies 变 量 中 。 

O 第 8 行 获取 iso-topologies 中 每 一 项 的 topology-id， 并 将 返回 的 topology-id 和 集合 保存 到 

iso-ids-set 变 量 中 。 

口 第 9 行 调用 topology-worker-specs 方 法 对 iso-topologies 进行 处 理 。 它 返回 一 个 
<topology-id，Listx<Set>> 集 合 ， 其 中 Listx<set> 中 的 每 一 项 都 是 一 个 Worker 上 的 Executor 
集合 。Executor 的 结构 是 [start-task-id，end-task-id]。 

口 第 10 行 调用 topology-machine-distribution 方 法 获取 与 每 一 个 需要 单独 进行 任务 分 配 的 
Topology 对 应 的 机 器 分 布 信息 ， 它 也 是 由 配置 项 中 的 isolation.scheduler.machines 参 数 
所 指定 的 。 该 方法 的 返回 结果 是 一 个 <topology-id，HashMap<worker-count，machine- 
count>> 集 合 , 其 中 哈 希 表 记 录 了 该 Topology 的 所 有 Worker 在 指定 机 器 上 的 数量 分 布 情况 。 

键 代表 有 几 个 Worker， 值 代表 有 几 台 机 器 会 被 分 配 到 该 键 所 指定 的 数量 的 Worker。 

a 第 11 行 调用 host-assignments 方 法 获取 当前 集群 中 机 融资 源 的 分 配 情况 。 它 返回 的 是 按照 
主机 名 进行 分 组 之 后 的 信息 , 每 个 分 组 里 面 的 信息 是 一 个 <slot, topology-id, executors> 

合 。 返 回 的 结果 将 被 保存 在 host-assignments 中 。 

口 第 12~29 行 对 前 面 获取 到 的 host-assignments 中 的 每 一 项 依次 进行 处 理 
u 第 13 行 获取 assignments 中 第 一 项 的 topology-id 信 息 。 

第 14 行 从 第 10 行 的 计算 结果 中 获取 与 topology-id 相 对 应 的 机 器 分 布 信息 , 即 一 个 哈 希 表 。 

第 15 行 从 第 9 行 的 计算 结果 中 获取 与 topology-id 相 对 应 的 Executor 信 息 。 

第 16 行 获取 当前 主机 上 被 分 配 的 任务 数目 并 将 其 作为 num-workers。 

第 18~29 行 首先 判断 当前 主机 上 的 所 有 assignment 是 否 满足 以 下 条 件 。 

e. 第 8 行 计算 出 来 的 iso-ids-set 中 是 否 包 含 第 13 行 获取 的 topology-id。 

e 当前 host 上 的 所 有 assignment 是 否 都 属于 由 第 13 行 获取 的 topology-id 所 指定 的 
Topology。 

e. 第 14 行 计算 出 来 的 哈 希 表 中 是 否 包含 以 第 16 行 计算 出 来 的 num-workers 为 键 的 项 。 

e. 第 15 行 计算 出 来 的 Executor 集 合 是 否 包 含 了 当前 主机 所 分 得 任务 的 所 有 Executor 信 息 。 

如 果 这 4 个 条 件 全 部 满足 ,那么 这 个 主机 符合 分 配 条 件 ， 不 需要 再 对 它 进 行 分 配 ， 只 需 
进行 以 下 操作 。 

调用 decrement-distribution! 方 法 更 新 第 14 行 的 结果 中 num-workers 对 应 的 机 器 数目 ， 

将 它 的 值 减 一 ， 即 已 经 有 一 台 机 器 符合 这 个 分 配 条 件 。 


o 
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口 


m 更 新 第 15 行 结果 的 Executor 集 合 ， 将 当前 这 人 台 机 器 上 所 有 满足 条 件 的 Executor 从 该 集合 
中 移 除 ， 只 对 剩 下 的 Executor 进 行 分 配 。 

将 满足 条 件 的 机 器 名 加 入 到 cluster 对 象 的 黑 名 单 中 ， 以 确保 不 会 再 对 这 人 台 机 需 进 行 任 
何 的 任务 分 配 。 
如 果 前 面 4 条 中 有 任何 一 个 条 件 不 满足 ， 那 么 就 遍历 该 机 器 上 所 有 的 任务 分 配 ， 判 断 它 
们 对 应 的 topology-id 是 否 属于 iso-ids-set 集 合 。 如 果 是 ， 则 调用 cluster 的 freeSlot 方 
法 将 与 该 任务 相对 应 的 slot 释 放 掉 。 

第 31 行 调用 host->used-slots 函 数 获 取 当 前 集群 中 的 <host，used-slots> 人 集合， 将 结果 保 

存在 host->used-slots 变 量 


口 第 32 行 调用 host-assignable-slots 方 法 获取 当前 集群 中 可 用 的 slot 资 源 集合 ， 并 将 结果 保 


存在 sorted-assignable-hosts 变 量 中 。 这 个 信息 是 一 个 <host，slots> 集 合 ， 且 它 是 按照 
slot 的 数目 降序 排列 的 。 

第 34~45 行 对 第 9 行 结 果 <topology-id，List<executors>> 中 的 每 一 项 进行 处 理 。 首 先 调用 
distribution->sorted-amts 方 法 计算 与 Topology 对 应 的 每 台 机 需 上 竺 分配 的 Worker 数 目 集 
合 ( 按 照 降序 排列 ), 并 将 该 集合 保存 在 amts 变 量 中 。 接 下 来 , 对 amts 中 的 每 一 项 进行 处 理 。 
首先 获取 sorted-assignable-hosts 中 的 第 一 个 [host, host-slots] 元 素 ( 此 时 并 不 会 将 元 素 
移 除 ， 这 里 取 第 一 个 元 素 是 因为 sorted-assignable-hosts 是 按照 机 器 可 用 的 slot 数 目 降 序 
排列 的 ， 而 amts 中 保存 的 Topology 所 需 的 Worker 数 目 集合 也 是 降序 排列 的 ， 这 就 确保 了 只 
要 检查 sorted-assignable-hosts 中 的 第 一 个 元 素 就 可 以 得 知 amt 是 否 能 满足 所 需 的 Worker 
数目 )。 如 果 host-slots 不 为 空 ， 并 且 host-slots 的 数目 大 于 等 于 该 Topology 需 要 的 数目 ， 
表明 该 机 器 可 被 用 于 分 配 。 这 时 才 会 真正 将 sorted-assignable-hosts 的 第 一 个 元 素 移 除 ， 
并 调用 cluster 的 freeslots 方 法 将 该 主机 上 所 有 正在 使 用 的 slot 释 放 掉 。 接 下 来 ， 从 该 机 器 
的 host-slots 列 表 中 取出 前 amt 个 slot, 其 中 每 一 个 slot 都 对 应 一 个 Worker, 每 一 个 slot 都 会 被 
分 配给 与 该 Topology 对 应 的 一 组 属于 同一 个 Worker 的 Executor 集 合 ( 第 9 行 计算 出 来 的 ), 最 
后 , 将 该 机 器 的 主机 信息 加 入 到 cluster 的 黑 名 单列 表 中 , 防止 该 机 器 再 次 被 用 于 进行 任务 
分 配 。 

第 47~50 行 用 于 判断 所 有 需要 单独 进行 任务 分 配 的 Topology 是 否 都 已 经 分 配 完 ， 并 返回 没 
有 分 配 完 的 topology-id 列 表 作为 failed-iso-topologies。 

第 51~64 行 判断 failed-iso-topologies 集 合 是 否 为 空 。 如 果 为 空 ， 代 表单 独 分 配 都 已 经 完 
成 , 接 下 来 要 做 的 是 从 当前 所 有 需要 进行 任务 分 配 的 Topology 中 移 除 这 些 需要 单独 分 配 并 
日 已 经 分 配 完成 的 Topology， 然 后 调用 DefaultScheduler 的 default-schedule 方 法 对 剩余 
的 Topology 进 行 任务 分 配 。 由 于 在 进行 单独 任务 分 配 的 过 程 中 已 经 将 成 功 分 配 的 机 器 加 入 
到 了 cluster 的 黑 名 单列 表 ， 所 以 这 里 对 剩余 的 Topology 进 行 分 配 时 只 会 使 用 不 在 黑 名 单 
列表 中 的 机 器 。 如 果 failed-iso-topologies 集 合 不 为 空 ， 表 明 这 些 需 要 单独 进行 任务 分 
配 的 Topology 没 有 全 部 分 配 完 成 。 这 时 会 打印 日 志 ， 记 录 下 哪些 Topology (也 即 
failed-iso-topologies 集 合 ) 还 没有 被 分 配 ， 然 后 遍历 当前 所 有 已 经 被 分 配 任务 的 机 器 ， 
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列表 中 ， 就 释放 掉 它 目前 占用 的 资源 。 这 一 步 的 目的 是 
为 了 确保 下 次 为 这 些 没有 完成 任务 分 配 的 Topology 进 行 分 配 时 有 足够 的 资源 。 
口 第 65 行 将 cluster 的 黑 名 单 : 


网 复 到 进行 任务 调度 之 前 的 值 ， 也 即 前 面 第 6 行 保存 的 初始 值 。 
7.5 调度 示例 


前 面 介绍 了 3 种 调度 策略 ， 下 面 我 们 举 一 个 实际 的 例子 来 看 一 下 不 同调 度 器 是 如 何 进行 任务 
分 配 的 。 
假设 当前 集群 中 有 6 侣 机 天 ， 


每 台 机 器 上 的 可 用 端口 均 为 6700、6701、6702 和 6703 ， 
集群 中 没有 正在 运行 的 Topology， 初 始 状 态 如 图 7-1 所 示 。 


且 当 前 


Si So 
6700 6701 6700 6701 
6702 6703 6702 6703 


S3 
6700 6701 
6702 6703 


图 7-1 


集群 初始 状态 
表 7-1 是 接 下 来 我 们 会 依次 提交 的 3 个 Topology。 
表 7-1 Scheduler 测 试 Topology 
Topology Worker 数 目 Executor 数 目 Task 数 目 
T-1 3 8 
T2 5 
T-3 


16 
10 10 
8 16 


鉴于 正常 情况 下 EvenSscheduler 和 DefaultSchedulez 的 调度 结果 是 一 致 的 , 我 们 把 这 两 种 方式 
放 在 一 起 介绍 ， 下 面 就 看 一 下 不 同 的 调度 器 对 分 配 结果 的 影响 。 
7.5.1 


EvenScheduler 和 和 DefaultScheduler 


在 这 一 节 中 ， 我 们 会 详细 介绍 分 别提 交 T-1、T-2 以 及 T-3 之 后 的 任务 调度 以 及 资源 分 配 情况 。 
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1. 提交 T-1 

提交 T-1 后 的 调度 过 程 如 下 。 

口 可 用 的 slot 列 表 经 过 sort-slots 方 法 处 理 后 的 结果 是 : {[S1 6700][S 2 6700][S; 6700] 
[S4 6700][S; 6700][S6 6700][S, 6701][S; 6701][S; 6701][S, 6701][Ss 6701][S 6701] 
[S, 6702][S, 6702][S; 6702][S, 6702][S; 6702][S。 6702][S, 6703][S; 6703][S; 6703] 
[S4 6703][Ss 6703][S6 6703]) 

口 compute-executors 方 法 计算 完 后 得 到 的 Executor 列 表 为 : {[1 2][3 4][5 6][7 8][9 10][11 12] 

[13 14][15 16]} 。 

O 8 个 Executor 在 3 个 Worker 上 的 分 布 情况 是 [3，3，2]。 

分 配 结果 如 下 : 

a {[1 2][3 4][5 6]} >[S1 6700] 

a {[7 8][9 10][11 12]} 2[S; 6700] 

a {[13 14][15 16]} O[S; 6700] 

此 时 集群 中 的 任务 分 配 情 况 如 图 7-2 所 示 。 


集群 


6702 


5 


S 
| mm | 
6702 


图 7-2 ”提交 完 T-1 后 集群 中 的 任务 分 配 情况 


2. 提交 T-2 

提交 T-2 后 的 调度 过 程 如 下 。 

口 可 用 的 slot 列 表 经 过 sort-slots 方 法 处 理 后 的 结果 是 : {[S1 6701][S» 6701] [S4 6701][S4 6700] 
[Ss 6700][S6 6700] [S; 6702][S; 6702][S3 6702][S4 6701][Ss 6701][S¢ 6701][S1 6703][S; 6703] 
[S3 6703][S 4 6702][S  6702][Ss 6702][S4 6703][S; 6703][S6 6703]) 。 

O compute-executors 方 法 计算 完 后 得 到 的 Executor 列 表 为 : ([1 1][2 2][3 3][4 4][5 5][6 6] 

[77][8 8][9 9][10 10]}. 

O 10 个 Executor 在 5 个 Worker 上 的 分 布 情况 是 [2, 2, 2, 2, 2]. 
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分 配 结果 如 下 : 

a {[1 1][2 2) 2[S; 6701] 

a {[3 3][4 4]] 2[S; 6701] 

a {[5 5][6 6]} 2 [S; 6701] 

a {[7 7][8 8) 2 [S; 6700] 

a {[9 9][10 10]? 2 [Ss 6700] 

此 时 集群 中 的 任务 分 配 情况 如 图 7-3 所 示 。 


S1 
6702 6703 


图 7-3 ”提交 完 T-2 后 集群 中 的 任务 分 配 情况 
3. 提交 T-3 
提交 T-3 后 的 调度 过 程 如 下 。 


O 可 用 的 slot 列 表 经 过 sort-slots 方 法 处 理 后 的 结果 是 : {[S; 6702][S; 6702][S3 6702][S4 6701] 


[Ss 6701][S6 6700] [S; 6703][S2 6703][S3 6703][S4 6702][S; 6702][Ss 6701][S4 6703][S; 6703] 

[S6 6702][S¢ 6703]} o 

口 compute-executors 方 法 计算 完 后 得 到 的 Executor 列 表 为 : {[1 1][2 2][3 3][4 4][5 5][6 6] 
[77][8 8][9 9][10 10][11 11][12 12][13 13][14 14][15 15][16 16]}. 

口 16 个 Executor 在 8 个 Worker 上 的 分 布 情况 是 [2, 2, 2, 2, 2, 2, 2, 2] 

分 配 结果 如 下 : 

a ([1 1][2 2]} >[S1 6702] 

口 {[3 3][4 4]} 2[S; 6702] 

a {[5 5][6 6]} >[S; 6702] 

a {[7 7][8 8]} >[S4 6701] 

口 {[9 9][10 10]}>[S; 6701] 

Q ([11 11][12 12]} 2[Se 6700] 
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a ([13 13][14 14]}>[S, 6703] 
OQ {[15 15][16 16]? 2[S; 6703] 
此 时 集群 中 的 资源 分 配 情况 如 图 7-4 所 示 。 


S 
6702 


图 7-4 ”提交 完 T-3 后 集群 中 的 最 终 分 配 结果 


由 此 也 可 以 看 出 ， 目 前 的 分 配 策略 是 有 问题 的 ， 最终 的 任务 分 布 并 不 均匀 。 


7.5.2 IsolationScheduler 
假设 我 们 将 T-3 设 置 为 需要 进行 单独 分 配 的 Topology， 并 设置 其 所 需要 的 机 器 数目 为 3， 下 面 
来 看 一 下 它 的 分 配 情况 。 
提交 工 1 和 工 2 时 的 任务 分 配 情况 跟前 面 使 用 DefaultSscheduler 和 EvenScheduler 进 行 分 配 是 一 


样 的 ， 此 时 集 稚 


的 状态 如 


图 7-3 所 示 。 


紧 接着 我 们 提交 T-3， 调 度 右 发 现 这 是 一 个 需要 单独 进行 分 配 的 Topology， 所 以 首先 会 计算 
它 的 任务 分 配 情况 ， 计 算 过 程 如 下 。 


a 设 定 它 需 


口 compute-executors 方 法 计算 完 后 得 到 的 Executor 列 表 : ([1 1][2 2][3 3][4 4][5 5][6 6][7 7] 
[8 8][9 9][10 10][11 11][12 12][13 13][14 14][15 15][16 16]}. 

O 16 个 Executor 在 8 个 Worker 上 的 分 布 情况 是 [2, 2, 2, 2, 2, 2, 2, 2]. 

H3 E Hlé ( 即 3 个 Supervisor )， 总 共有 8 个 Worker， 所 以 Worker 在 机 器 上 的 分 布 


情况 按 降 序 排 列 是 [3, 3, 2]. 
接 下 来 检查 当前 集群 中 是 否 有 已 经 分 配给 该 Topology 的 资源 。 如 果 有 ， 进 一 步 检 查 当前 机 器 
上 是 否 只 有 属于 该 Topology 的 Worker， 且 Worker 数 目 是 否 符合 我 们 计算 的 分 布 情况 ( 这 里 就 是 有 
3 个 或 2 个 )。 如果 不符 合 要 求 ， 就 将 当前 机 器 上 所 有 分 配给 需要 单独 进行 分 配 的 Topology 的 资源 
都 释放 掉 ， 本 例 中 这 一 步 没 做 任何 事情 。 接 下 来 获取 系统 中 所 有 的 可 用 资源 ， 并 按照 主机 名 进行 
分 组 操作 ， 然 后 将 分 组 后 的 可 用 资源 按 数目 从 大 到 小 排列 。 这 一 步 返回 的 结果 是 : 
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{{Se, {[Se 6700][Se 6701 ][S_ 6702][S5 6703]}}, 

{Ss, {[Ss 6701][S5 6702][Ss 6703]}}, 

1S4, {[S4 6701][S4 6702][S4 6703]}}, 

{S3, {[S3 6702][S; 6703]}}, 

185, {[S2 6702][S2 6703]}}, 

{S1, {[S1 6702][S; 6703]}}} 

也 即 Se 上 有 4 个 可 用 资源 ，S5、S4 上 有 3 个 可 用 资源 ，S3、S> 和 Si 上 都 有 两 个 可 用 资源 。 

我 们 已 经 计算 得 知 Worker 的 分 布 是 [3, 3, 2]. 首先 判断 可 用 机 器 Se6 上 能 否 启动 3 个 该 Topology 
的 Worker。 此 处 可 以 , 所 以 会 将 Sk 算 作 符 合 分 配 条 件 的 机 器 。 同 时 若 Se 上 已 经 有 了 在 运行 的 任务 ， 
则 会 被 释放 挤 ， 然 后 在 这 人 台 机 器 上 为 该 Topology 分 配 3 个 Worker: 
o {[1 1][2 2] >[Se 6700] 
a {[3 3][4 4] >[Se 6701] 
a {[5 5][6 6] >[Se 6702] 

同时 会 把 Se 机 器 加 入 到 cluster 对 象 的 黑 名 单 中 。 

接 下 来 判断 Ss 上 能 否 启动 3 个 属于 该 Topology 的 Worker， 这 里 也 是 可 以 的 。 所 以 它 也 算 符合 
条 件 的 机 器 , 因此 释放 掉 它 上 面 已 经 启动 的 属于 工 2 的 一 个 Worker, 然后 在 该 机 器 上 为 该 Topology 
分 配 3 个 Worker: 
a [7 7][8 8]}>[Ss 6700] 
a ff9 9][10 10]}>[Ss 6701] 
a (ui 11][12 12]} 2[8; 6702] 

同时 把 Ss 机 器 加 入 到 cluster 对 象 的 黑 名 单 中 。 

同 理 ， 接 下 来 判断 $4 上 是 否 能 启动 两 个 该 Topology 的 Worker， 这 里 也 是 可 以 的 。 所 以 $4 同样 
也 是 符合 分 配 条 件 的 机 器 ， 因 此 释放 掉 它 上 面 已 经 启动 的 属于 T-2 的 一 个 Worker， 然 后 在 该 机 器 
上 为 该 Topology 分 配 两 个 Worker: 
a {[13 13][14 14]} >[S4 6700] 
a {[15 15][16 16]} 2[S; 6701] 

最 后 ,将 $4 也 加 入 到 cluster 对 象 的 黑 名 单 中 。 

至 此 就 完成 了 对 T; 的 任务 分 配 。 接 下 来 通过 调用 DefaultScheduler 为 之 前 释放 掉 的 T-2 的 两 个 
Worker 重 新 分 配 资源 ， 最 终 的 分 配 如 图 7-5 所 示 。 
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图 7-5 _ IsolationScheduler 最 终 分 配 情况 
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Supervisor 可 理解 为 单机 任务 调度 器 ， 它 负责 监听 Nimbus 的 任务 调度 ， 启 动 相应 的 Worker 对 
Nimbus 分 配 的 任务 进行 处 理 。 同 时 , 它 也 会 监测 由 它 启动 的 Worker 的 运行 状态 ,一 旦 发 现 有 Worker 
处 于 非 正 党 状态 ,就 会 杀 掉 该 Worker, 并 将 原来 分 配给 该 Worker 的 任务 交还 Nimbus 进 行 重 新 分 配 。 


8.1 与 Supervisor 相关 的 数据 结构 


首先 我 们 来 介绍 一 些 Supervisor 中 定义 的 常用 方法 与 数据 结构 ， 具 体 如 下 所 示 。 

口 standalone-supervisor 方 法 : 它 会 创建 一 个 实现 了 ISupervisor 接 口 的 对 象 ， 其 中 定义 了 

一 些 常 用 方法 。 

口 supervisor-data 方 法 则 创建 了 一 个 映射 集合 ， 这 是 Supervisor 中 一 个 非常 重要 的 数据 结 

构 ， 它 包含 了 很 多 会 被 其 他 方法 共享 的 成 员 。 

口 Supervisor 使 用 LocalState 在 本 地 保存 了 自己 的 ID 信息 、LocalAssignment 信 息 以 及 有 效 的 从 
Worker 到 端口 号 的 映射 关系 。 


8.1.1 standalone-supervisor 


这 个 方法 返回 一 个 实现 了 ISupervisor 接 口 的 对 象 ， 它 可 以 用 来 获取 和 创建 Supervisor 的 id， 
也 可 以 用 来 获取 配置 给 当前 Supervisor 的 所 有 可 用 端口 列表 。 下 面 我 们 仔细 看 一 下 它 的 实现 ， 其 
代码 如 下 : 


1 (defn standalone-supervisor [] 

2 (let [conf-atom (atom nil) 

3 id-atom (atom nil)] 

4 (reify ISupervisor 

5 (prepare [this conf local-dir] 

6 (reset! conf-atom conf) 

7 (let [state (LocalState. local-dir) 

8 curr-id (if-let [id (.get state LS-ID)] 


9 id 

10 (generate-supervisor-id))] 
11 (.put state LS-ID curr-id) 

12 (xeset! id-atom curr-id)) 
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14 (confirmAssigned [this port] 
15 true) 

16 (getMetadata [this] 

17 (doall (map int (get Gconf-atom SUPERVISOR-SLOTS-PORTS)))) 
18 (getSupervisorId [this] 

19 @id-atom) 

20 (getAssignmentId [this] 

21 @id-atom) 

22 (killedWorker [this port] 

23 ) 

24 (assigned [this ports] 

25 )))) 


eh 


O 第 5~13 行 定义 的 prepare 方 法 用 来 保存 当前 Supervisor 使 用 的 配置 信息 ， 获 取 和 创 到 
Supervisor 的 id， 以 及 将 该 标识 保存 在 id-atom 中 。 

a 第 14~15 行 定义 的 confirmAssigned 方 法 用 于 确认 一 个 端口 是 否 已 被 分 配 ， 目 前 直接 返回 
true. 

a 第 16~17 行 定义 的 getMetadata 方 法 从 配置 中 获取 该 Supervisor 的 所 有 可 用 端口 号 信息 。 

O 第 18~19 行 定义 的 getSupervisorId 和 第 20 ~ 21 行 定义 的 getAssignmentId 方 法 的 实现 目前 
是 相同 的 ， 返 回 的 都 是 该 Supervisor 的 id 信息 。 

O 第 22 ~ 25 行 定义 的 killedWorker 和 assigned 方 法 目前 没有 使 用 。 


8.1.2 ” Supervisor 的 数据 


supervisor-data 方 法 定义 了 整个 Supervisor 代 码 的 共享 数据 结构 ， 其 中 包括 了 很 多 常用 的 成 
员 变 量 。 它 在 Supervisor 启 动 时 创建 ， 并 在 接 下 来 的 过 程 中 在 许多 方法 中 作为 参数 传人 ， 相 关 代 
码 如 下 : 


(defn supervisor-data [conf shared-context ^ISupervisor isupervisor] 
{:conf conf 
:shared-context shared-context 
:isupervisor isupervisor 
:active (atom true) 
:uptime (uptime-computer) 
:worker-thread-pids-atom (atom {}) 
:storm-cluster-state (cluster/mk-storm-cluster-state conf) 
:local-state (supervisor-state conf) 
:supervisor-id (.getSupervisorId isupervisor) 
:assignment-id (.getAssignmentId isupervisor) 
:my-hostname (if (contains? conf STORM-LOCAL-HOSTNAME ) 
(conf STORM-LOCAL-HOSTNAME ) 
(local-hostname) ) 
:curr-assignment (atom nil) ;; used for reporting used ports when heartbeating 
:timer (mk-timer :kill-fn (fn [t] 
(log-error t "Error when processing event") 
(halt-process! 20 "Error when processing an event") 
)) 
p 
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我 们 分 别 介绍 一 下 这 些 成 员 变 量 的 作用 。 

口 :conf 是 Supervisor 启 动 时 使 用 的 配置 信息 。 

口 :shared-context 可 用 于 传递 一 些 与 上 下 文 相关 的 信息 ， 目 前 没有 使 用 (默认 为 nil )。 
O :isupervisor 是 一 个 实现 了 ISupervisor 接 口 的 对 象 ， 这 里 就 是 通过 前 面 介绍 的 
standalone- supervisor 方 法 获取 的 一 个 实例 。 

:active 表 明 Supervisor 的 运行 状态 。 

:uptime 表 明 Supervisor 迄 今 为 止 的 运行 时 间 。 

:worker-thread-pids-atom 存 储 Supervisor 启 动 的 所 有 Worker 的 进程 号 集合 。 
:storm-cluster-state 用 来 获取 或 存储 与 Storm 集 群 相关 的 元 数据 信息 。 

:local-state 创 建 该 Supervisor 的 LocalState 存 储 对 象 。 

:supervisor-id 为 当前 Supervisor 的 身份 标识 。 

:assignment-id 目 前 等 同 于 :supervisor-id。 

:my-hostname 记 录 了 当前 Supervisor 的 主机 名 信息 。 

:curr-assignment 记 录 了 当前 Supervisor 已 经 使 用 的 端口 号 信息 。 
:timer 是 Supervisor 创 建 的 计时 器 ， 用 于 执行 周期 性 的 任务 。 


8.1.3 ”本 地 存储 数据 


为 了 确保 Supervisor 在 失败 重启 后 能 继续 正常 运行 ， 它 在 本 地 存储 了 一 些 重 要 的 数据 结构 ， 
这 些 数据 都 是 通过 Localstate 保 存 的 ， 下 面 简要 介绍 一 下 。 

1. Supervisor Id 

Supervisor 将 自己 的 id 保存 在 路 径 STORM-LOCAL-DIR/supervisorisupervisor 下, 保存 时 使 用 
的 键 是 supervisor-id。 这 样 就 算 Supervisor 服 务 被 重启 ，Supervisor 仍 然 可 以 通过 LocalState 获 取 
自己 的 supervisor-id。 


DoOOOOOOODO DO 


2. LocalAssignment 
它 记 录 了 Supervisor 上 从 storm-id ( topology-id ) 到 分 配给 该 Supervisor 的 所 有 Executor 的 对 
应 关系 ， 相 关 代 码 如 下 : 


(defrecord LocalAssignment [storm-id executors]) 


Supervisor] 3x 26 [5 ELE TERRE TS STORM-LOCAL-DIR/supervisor/localstate/ F ， 保 存 时 使 用 
的 键 是 local-assignments。Supervisor 每 次 跟 Nimbus 同 步 时 ， 都 会 将 自己 本 地 保存 的 目前 分 配 与 
从 Nimbus 获 取 的 最 新 分 配 相 比较 , 者 发 现 分 配给 自己 的 任务 发 生变 化 , 则 做 出 相应 处 理 并 将 本 地 
记录 更 新 为 目前 分 配 。Supervisor 服 务 重启 后 , 仍然 可 以 通过 Localstate 获 取 自 己 上 次 被 分 配 的 任 
务 ， 从 而 可 以 继续 正常 工作 。 

3. Approved Workers 

它 主要 保存 当前 Supervisor 机 器 上 有 效 的 <worker-id，port> 映 射 集合 。Supervisor 将 这 些 信息 
也 保存 在 路 径 STORM-LOCAL-DIR/supervisorlocalstate/ 下 , 保存 时 使 用 的 键 是 approved-workers。 
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Supervisor 每 次 跟 它 启动 的 Worker 进 程 同 步 时 ， 首 先 会 通过 获取 本 地 保存 的 任务 分 配 信 息 得 到 最 
新 的 任务 分 配 情况 ， 接 下 来 会 检查 当前 已 经 启动 的 Worker 是 否 都 还 活着 (心跳 一 直 更 新 )， 然 后 
根据 这 些 信息 计算 出 哪些 Worker 需 要 关闭 、 哪 些 Worker 需 要 启动 ， 从 而 计算 出 新 的 approved-worker 
集合 , 并 将 更 新 后 的 内 容 保 存在 LocalState 数 据 中 。Supervisor 服 务 重启 后 , 仍 可 获得 由 它 启 动 的 
正在 运行 的 Worker 列 表 ， 从 而 继续 正常 工作 。 


8.2 Supervisor 中 的 线程 


Supervisor 中 有 3 个 线程 , 一 个 计时 器 线程 以 及 两 个 事件 线程 。 计 时 需 线 程 主要 负责 维持 心跳 ， 
也 即 更 新 ZooKeeper 中 保存 的 当前 Supervisor 的 最 新 状态 , 同时 也 负责 每 隔 一 段 时 间 将 事件 线程 要 
执行 的 事件 添加 到 其 对 应 的 队列 中 ; 在 两 个 事件 线程 中 , 一 个 负责 与 Nimbus 同 步 任务 , 另 一 个 则 
负责 根据 任务 变化 同步 管理 Worker 进 程 。 


8.2.1 计时 器 线程 


计时 器 线程 会 每 隔 固 定 的 时 间 间 隔 运 行 一 遍 下 面 定 义 的 函数 ， 其 中 时 间 间 隔 由 参数 
SUPERVISOR-HEARTBEAT-FREOUENCY-SECS 定 义 (默认 值 是 $ 秒 ): 


1 fn [] (.supervisor-heartbeat! 
2 (:storm-cluster-state supervisor) 

3 (:supervisor-id supervisor) 

4 (SupervisorInfo. (current-time-secs) 
5 (:my-hostname supervisor) 

6 (:assignment-id supervisor) 

7 (keys @(:curr-assignment supervisor)) 
8 33 used ports 

9 (.getMetadata isupervisor) 

10 (conf SUPERVISOR-SCHEDULER-META) 
11 ((:uptime supervisor) ))) 


该 方法 会 更 新 保存 在 ZooKeeper 中 的 该 Supervisor 的 信息 , 这 样 保证 了 Nimbus 在 进行 新 一 轮 任 
务 分 配 时 ， 会 及 时 得 知 当 前 集群 中 各 个 Supervisor 的 最 新 状态 。 

除 此 之 外 ， 计 时 器 线程 还 会 每 隔 10 秒 将 mk-synchronize-supervisor 方 法 加 入 到 同步 Nimbus 
任务 的 事件 线程 中 ， 每 隔 SUPERVISOR-MONITOR-FREOUENCY-SECS ( 默认 是 3 秒 ) 将 sync-processes 方 
法 加 入 到 同步 管理 Worker 进 程 的 事件 线程 中 。 


8.2.2 同步 Nimbus 任 务 的 线程 


Ge Fiol WA Br TAE T mk- synchronize-supervisor PK BOK (x HE Supervisor Ej Nimbus HJ 4E 3 [1] 
AG, 以 及 时 获取 Nimbus 分 配给 该 Supervisor 的 新 任务 , 并 移 除 那些 已 经 分 配 但 不 再 需要 的 旧 任 务 。 
在 这 个 处 理 过 程 ，Supervisor 会 将 每 次 同步 后 的 LocalAssignment 信 息 更 新 到 LocalState 中 。 

下 面 我 们 看 一 下 这 个 函数 的 实现 ， 其 代码 如 下 : 
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1 (defn mk-synchronize-supervisor [supervisor sync-processes event-manager processes-event-manager] 
2 (fn this [] 

3 (let [conf (:conf supervisor) 

4 storm-cluster-state (:storm-cluster-state supervisor) 

5 ^ISupervisor isupervisor (:isupervisor supervisor) 

6 ^LocalState local-state (:local-state supervisor) 

7 sync-callback (fn [& ignored] (.add event-manager this)) 

8 storm-code-map (read-storm-code-locations storm-cluster-state sync-callback) 

9 downloaded-storm-ids (set (read-downloaded-storm-ids conf)) 


10 all-assignment (read-assignments 

11 storm-cluster-state 

12 (:assignment-id supervisor) 

13 sync-callback) 

14 new-assignment (-»» all-assignment 

15 (filter-key #(.confirmAssigned isupervisor %))) 
16 assigned-storm-ids (assigned-storm-ids-from-port-assignments new-assignment) 
17 existing-assignment (.get local-state LS-LOCAL-ASSIGNMENTS)] 
18 (log-debug "Synchronizing supervisor") 

19 (log-debug "Storm code map: " storm-code-map) 

20 (log-debug "Downloaded storm ids: " downloaded-storm-ids) 

21 (log-debug "All assignment: " all-assignment) 

22 (log-debug "New assignment: " new-assignment) 

23 

24 (doseq [[storm-id master-code-dir] storm-code-map] 

25 (when (and (not (downloaded-storm-ids storm-id) ) 

26 (assigned-storm-ids storm-id)) 

27 (log-message "Downloading code for storm id " 

28 storm-id 

29 " from " 

30 master-code-dir) 

31 (download-storm-code conf storm-id master-code-dir) 
32 (log-message "Finished downloading code for storm id " 
33 storm-id 

34 " from " 

35 master-code-dir) 

36 ) 

37 

38 (log-debug "Writing new assignment " 

39 (pr-str new-assignment)) 

40 (doseq [p (set/difference (set (keys existing-assignment)) 
41 (set (keys new-assignment)))] 

42 (.killedWorker isupervisor (int p))) 

43 (.assigned isupervisor (keys new-assignment)) 

44 (.put local-state 

45 LS-LOCAL-ASSIGNMENTS 

46 new-assignment) 

47 (reset! (:curr-assignment supervisor) new-assignment) 

48 (if on-windows? (shutdown-disallowed-workers supervisor)) 
49 (doseq [storm-id downloaded-storm-ids] 

50 (when-not (assigned-storm-ids storm-id) 

51 (log-message "Removing code for storm id " 

52 storm-id) 

53 (try 

54 (rmr (supervisor-stormdist-root conf storm-id)) 


55 (catch Exception e (log-message (.getMessage e)))) 
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56 ) 
57 (.add processes-event-manager sync-processes) 
58 0) 


首先 介绍 该 方法 涉及 的 参数 。 

O) supervisor: supervisor-data 对 象 。 

口 sync-processes: mk-supervisor 中 定义 的 用 于 同步 当前 Supervisor 启 动 的 Worker 的 方法 。 

它 负责 关闭 被 移 除 的 Worker， 以 及 启动 新 分 配 的 Worker。 

口 event-manager: mk-supervisor 中 定义 的 运行 mk-synchronize-supervisor 方 法 的 线程 。 

口 processes-event-manager: mk-supervisor 中 定义 的 运行 sync-processes 方 法 的 线程 

下 面 简 述 各 行 代码 的 作用 。 

a 第 3~6 行 依次 获取 supervisor-data 中 的 配置 信息 、storm-local-cluster 、isupervisor 和 

local-state 对 象 ， 并 将 它们 分 别 保存 到 对 应 的 临时 变量 

口 第 7 行 定义 sync-callback 方 法 ， 它 会 简单 地 将 mk-synchronize-supervisor 方 法 再 次 加 入 到 
同步 Nimbus 任 务 的 事件 线程 中 执行 。 这 个 方法 主要 用 来 在 进行 ZooKeeper 操 作 时 设置 回调 
方法 ， 另 外 当 ZooKeeper 中 的 内 容 发 生变 化 时 也 会 调用 该 方法 。 

a 第 8 行 通 过 调用 read-storm-code-locations 方 法 获取 <storm-id，master-code-location> 集 合 信 

息 作 为 storm-code-map。 在 read-storm-code-locations 方 法 中 ， 会 先 调用 storm-cluster-state 
的 assignments 方 法 获取 ZooKeeper 中 当前 保存 的 storm-id 信 息 ， 这 里 就 会 使 用 第 7 行 定义 
的 回调 方法 。 当 ZooKeeper 中 的 任务 分 配 信息 发 生变 化 时 (增加 或 删除 Topology )， 就 会 调 
用 该 回调 方法 及 时 处 理 这 些 变化 。 

口 第 9 行 通 过 调用 read-downloaded-storm-ids 方 法 获取 当前 已 下 载 Topology 所 对 应 的 Storm 

id 信 息 。 

口 第 10~13 行 调用 read-assignments 方 法 获取 分 配给 当前 Supervisor 的 任务 信息 ， 并 返回 一 个 

<port，LocalAssignment> 集 合作 为 al1-assignment 的 内 容 。 

a 第 14~15 行 对 前 面 计 算出 来 的 a1l1-assignment 进 行 过 滤 ， 只 保留 其 中 已 经 被 确认 分 配 的 
«port, LocalAssignment> 信 息 作 为 new-assignment (在 当前 的 实现 中 , 这 一 步 什 么 都 没 做 ， 
所 以 实际 上 new-assignment 跟 al1-assignment 是 一 样 的 )。 

口 第 16 行 调用 assigned-storm-ids-from-port-assignments 方 法 获取 new-assignment 的 

storm-id 信 息 作 为 assigned-storm-ids。 

a 第 17 行 获取 local-state 中 保存 的 LS-LOCAL-ASSIGNMENTS 信 息 作 为 existing-assignment, 它 

是 一 个 <port，Assignment> 集 合 。 

a 第 24~36 行 调用 download-storm-code 下 载 当前 已 经 分 配给 该 Supervisor 但 还 没有 下 载 到 本 

地 的 Topology 信 息 。 

口 第 40~42 行 首先 计算 出 属于 existing-assignment 但 不 属于 new-assignment 的 端口 信息 , 然后 
调用 isupervisor 的 killedWorker 方 法 关闭 这 些 端口 上 对 应 的 Worker ( 目前，killedWorker 
方法 是 一 个 空 方法 )。 
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O 第 43 行 调用 isupervisor 的 assigned 方 法 设置 新 分 配 的 端口 信息 。 

O 第 44~46 行 更 新 local-state 中 保存 的 LS-LOCAL-ASSIGNMENTS 信 息 ， 将 其 设置 为 new-assignment。 
口 第 47 行 更 新 supervisor-data 中 的 :curr-assignment 信 息 ， 将 其 设置 为 new-assignment。 

a 第 48 行 判断 当前 操作 系统 是 否 为 Windows, 47, JUDE Al shutdown-disallowed-workers 77 
法 将 状态 为 :disallowed 的 Worker 关 闭 。 

a 第 49~56 行 移 除 本 地 已 经 下 载 的 但 已 不 在 assigned-storm-ids 中 的 Topology 信 息 。 

O 第 57 行 将 sync-processes 方 法 添加 到 processes-event-manager 中 执行 ， 这 么 做 是 为 了 确保 当 
Supervisor 与 Nimbus 同 步 完 任务 分 配 之 后 ， 立 即 调用 sync-processes 方 法 同步 Worker 进 程 。 


8.2.3 管理 Worker 进 程 的 线程 


该 线程 通过 不 断 执 行 sync-processes 函 数 来 管理 由 该 Supervisor 启 动 的 所 有 Worker 进 程 , 这 种 
管理 包括 关闭 当前 不 处 于 :valid 状 态 的 Worker, 以 及 启动 新 分 配给 该 Supervisor 的 Worker。 在 这 个 
处 理 过 程 中 ，Supervisor 会 将 每 次 同步 完 后 的 Approved Workers 信 息 更 新 到 Localstate 中 。 

下 面 我 们 看 一 下 这 个 方法 的 具体 实现 ， 相 关 代 码 如 下 : 


1 (defn sync-processes [supervisor] 

2 (let [conf (:conf supervisor) 

3 ^LocalState local-state (:local-state supervisor) 

4 assigned-executors (defaulted (.get local-state LS-LOCAL-ASSIGNMENTS) {}) 
5 now (current-time-secs) 

6 allocated (read-allocated-workers supervisor assigned-executors now) 

7 keepers (filter-val 

8 (fn [[state ]] (= state :valid)) 


9 allocated) 

10 keep-ports (set (for [[id [ hb]] keepers] (:port hb))) 

11 reassign-executors (select-keys-pred (complement keep-ports) assigned-executors) 
12 new-worker-ids (into 

13 {} 

14 (for [port (keys reassign-executors) ] 

15 [port (uuid)])) 

16 

17 


18 (log-debug "Syncing processes") 

19 (log-debug "Assigned executors: " assigned-executors) 
20 (log-debug "Allocated: " allocated) 

21. (doseq [[id [state heartbeat]] allocated] 


22 (when (not= :valid state) 

23 (log-message 

24 "Shutting down and clearing state for id " id 
25 ". Current supervisor time: " now 

26 ". State: " state 

27 ", Heartbeat: " (pr-str heartbeat) ) 

28 (shutdown-worker supervisor id) 

29 )) 

30 (doseq [id (vals new-worker-ids)] 

31 (local-mkdirs (worker-pids-root conf id))) 


32 (.put local-state LS-APPROVED-WORKERS 
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33 (merge 

34 (select-keys (.get local-state LS-APPROVED-WORKERS) 
35 (keys keepers)) 

36 (zipmap (vals new-worker-ids) (keys new-worker-ids)) 
37 

38 (wait-for-workers-launch 

39 conf 

40 (dofor [[port assignment] reassign-executors] 

41 (let [id (new-worker-ids port)] 

42 (log-message "Launching worker with assignment " 
43 (pr-str assignment) 

44 " for this supervisor " 

45 (:supervisor-id supervisor) 

46 " on port " 

47 port 

48 " with id " 

49 id 

50 

51 (launch-worker supervisor 

52 (:storm-id assignment) 

53 port 

54 id) 

55 id))) 

56 — )) 


在 这 个 方法 中 ， 参 数 supervisor 是 一 个 supervisor-data 对 象 ， 下 面 简 述 各 行 代码 的 作用 。 

口 第 4 行 从 local-state 中 获取 LS-LOCAL-ASSIGNMENTS 和 集合 (一 个 <port，Assignment> 集 

合 )， 默 认 返 回 一 个 空 集合 。 

口 第 5 行 获取 当前 系统 时 间 。 

O 第 6 行 调用 read-allocated-workers 获 取 当 前 已 经 分 配 的 Worker 信 息 ， 返 回 的 是 一 个 
«worker-id, «worker state, worker heartbeat>> 集 合 ， 其 中 记录 了 与 当前 分 配 的 Worker 
相对 应 的 状态 和 心跳 信息 。 

O 第 7~9 行 对 第 6 行 返回 的 <worker-id，<worker-state，worker heartbeat>> 集 合 进行 过 滤 ， 

只 保留 其 中 worker-state 为 :valid 的 Worker。 

口 第 10 行 从 第 7~9 行 中 过 滤 出 来 的 Worker 心 跳 信息 中 获取 其 所 对 应 的 端口 信息 ， 并 将 其 作为 

要 保留 的 端口 信息 。 

a 第 11 行 利用 前 面 计算 出 来 的 要 保留 的 端口 信息 ， 从 第 4 行 获取 到 的 当前 已 经 被 分 配 的 

Executor 中 确定 需要 被 重新 分 配 的 Executor 信 息 ， 返 回 值 是 一 个 cport，Assignment> 集 合 。 

口 第 12~15 行 利用 第 11 行 计算 出 来 的 需 重新 分 配 的 Executor 信 息 ， 为 其 中 的 每 个 端口 创建 一 

个 新 的 worker-id， 并 返回 <port，worker-id> 集 合 。 

a 第 21~29 行 对 第 6 行 返回 的 集合 中 的 每 一 项 进行 处 理 ， 判 断 其 worker-state 是 否 为 :valid， 

如 果 不 是 就 打印 日 志 并 调用 shutdown-worker 方 法 关闭 该 Worker。 

口 第 30~31 行 对 于 第 12~15 行 返回 的 <port，worker-id> 集 合 中 的 每 一 个 worker-id 创 建 pid 文 
件 夹 ， 其 路 径 是 STORM-LOCAL-DIR/workers/<worker-id>/pids/。 
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O 第 32~37 行 更 新 local-state 中 存储 的 LS-APPROVED-WORKERS 信 息 。 更 新 的 方式 是 : 首先 获取 
当前 local-state 中 存储 的 LS-APPROVED-NORKERS 信 息 , 然后 根据 第 7~9 行 计算 出 的 所 有 仍然 
有 效 的 Worker 的 worker-id 进 行 过滤 ， 只 保留 继续 有 效 的 Worker 信 息 ， 接 下 来 将 第 12~15 
行 计算 出 来 的 新 的 cport，worker-id> 集 合 转换 为 <cworker-id，port> 和 集合， 最 后 将 这 两 部 
分 进行 合并 , 并 将 合并 后 的 结果 作为 新 的 LS-APPROVED-WORKERS 信 息 保 存 到 local-state 中 。 

O 第 38~56 行 首先 对 第 11 行 中 返回 的 重新 分 配 的 <port，Assignment> 集 合 中 的 每 一 项 ， 根 据 
端口 信息 从 第 12~15 行 返回 的 <port, worker-id> 中 获取 其 对 应 的 worker-id, 然后 打印 启动 
Worker 的 日 志 ， 调 用 launch-worker 方 法 启动 Worker， 并 返回 这 些 启动 的 Worker 的 
worker-id， 最 后 调用 wait-for-workers-launch 方 法 等 待 这 些 Worker 启 动 起 来 。 
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supervisor KOR X Z. F ETAR EH 


launch 方 法 用 于 启动 Supervisor 服 务 ， 它 主要 通过 调用 mk-supervisor 方 法 来 启动 Supervisor 服 
相关 代码 如 下 : 


1 (defn -launch [supervisor] 

2 (let [conf (read-storm-config)] 

3 (validate-distributed-mode! conf) 

4 (mk-supervisor conf nil supervisor))) 


在 这 个 方法 中 ,传人 的 参数 是 一 个 实现 了 ISupervisor 接 口 的 对 象 , 这 里 默认 使 用 standalone- 


o 


a 第 2 行 读 取 当前 Supervisor 启 动 时 所 需 的 配置 信息 。 

a 第 3 行 调用 validate-distributed-model! 方 法 ,根据 前 面 读 取 的 配置 信息 验证 系统 当前 是 否 
处 于 分 布 式 模式 。 

口 第 4 行 调用 mk-supervisor 方 法 创建 并 启动 Supervisor。 

下 面 我 们 来 看 一 下 mk-supervisor 方 法 的 具体 实现 ， 相 关 代 码 如 下 : 


1 (defserverfn mk-supervisor [conf shared-context ^ISupervisor isupervisor] 

2 (log-message "Starting Supervisor with conf " conf) 

3 (.prepare isupervisor conf (supervisor-isupervisor-dir conf)) 

4 (FileUtils/cleanDirectory (File. (supervisor-tmp-dir conf))) 

5 (let [supervisor (supervisor-data conf shared-context isupervisor) 

6 [event-manager processes-event-manager :as managers] [(event/event-manager false) 
(event/event-manager false)] 


7 sync-processes (partial sync-processes supervisor) 

8 synchronize-supervisor (mk-synchronize-supervisor supervisor sync-processes event 
-manager processes-event-manager) 

9 heartbeat-fn (fn [] (.supervisor-heartbeat! 

10 (:storm-cluster-state supervisor) 

11 (:supervisor-id supervisor) 

12 (SupervisorInfo. (current-time-secs) 

13 (:my-hostname supervisor) 


14 (:assignment-id supervisor) 
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15 (keys @(:curr-assignment supervisor) ) 

16 33 used ports 

17 (.getMetadata isupervisor) 

18 (conf SUPERVISOR-SCHEDULER-META) 

19 ((:uptime supervisor)))))] 

20 (heartbeat-fn) 

21 33 should synchronize supervisor so it doesn't launch anything after being down (optimization) 

22 (schedule-recurring (:timer supervisor) 

23 0 

24 (conf SUPERVISOR-HEARTBEAT-FREOUENCY-SECS ) 

25 heartbeat-fn) 

26 (when (conf SUPERVISOR-ENABLE) 

27 33 This isn't strictly necessary, but it doesn't hurt and ensures that the machine 
stays up 

28 33 to date even if callbacks don't all work exactly right 

29 (schedule-recurring (:timer supervisor) 0 10 (fn [] (.add event-manager synchronize 
-supervisor))) 

30 (schedule-recurring (:timer supervisor) 

31 0 

32 (conf SUPERVISOR-MONITOR-FREQUENCY- SECS ) 

33 (fn [] (.add processes-event-manager sync-processes)))) 

34 (log-message "Starting supervisor with id " (:supervisor-id supervisor) " at host " 

(:my-hostname supervisor)) 

35 (xeify 

36 Shutdownable 

37 (shutdown [this] 

38 (log-message "Shutting down supervisor " (:supervisor-id supervisor) ) 

39 (reset! (:active supervisor) false) 

40 (cancel-timer (:timer supervisor)) 

41 (.shutdown event-manager) 

42 (.shutdown processes-event-manager) 

43 (.disconnect (:storm-cluster-state supervisor))) 

44 SupervisorDaemon 

45 (get-conf [this] 

46 conf) 

47 (get-id [this] 

48 (:supervisor-id supervisor)) 

49 (shutdown-all-workers [this] 

50 (let [ids (my-worker-ids conf)] 

51 (doseq [id ids] 

52 (shutdown-worker supervisor id) 

53 ))) 

54 DaemonCommon 

55 (waiting? [this] 

56 (or (not @(:active supervisor)) 

57 (and 

58 (timer-waiting? (:timer supervisor)) 

59 (every? (memfn waiting?) managers))) 

60 )))) 


首先 介绍 mk-supervisor 中 涉及 的 参数 。 
口 conf: 启动 该 Supervisor 所 用 的 Storm 配 置 项 。 
口 shared-context: 启动 该 Supervisor 所 用 的 上 下 文 信息 ， 目 前 没有 使 用 。 


8.5 重要 方法 介绍 147 


口 isupervisor: 实现 了 ISupervisor 接 口 的 对 象 ， 这 里 默认 使 用 standalone-supervisor。 
下 面 简 述 各 行 代码 的 作用 。 

口 第 3 行 调用 isupervisor 的 prepare 方 法 。 这 里 ， 传 人 的 Supervisor id 的 保存 路 径 为 : 
STORM-LOCAL-DIR/supervisor/isupervisor o 

口 第 4 行 清理 supervisor-tmp-dir， 路 径 为 : STORM-LOCAL-DIR/supervisor/tmp j 

O 第 5 行 创建 supervisor-data， 这 个 对 象 前 面 介绍 过 。 

口 第 6~33 行 创建 并 启动 我 们 前 面 介绍 过 的 3 个 线程 。 

O 第 35~60 行 返回 一 个 实现 了 Shutdownable 、SupervisorDaemon 和 DaemonCommon 接 口 的 对 象 ， 
目前 这 个 没有 用 到 。 


8.4 关闭 Supervisor 
关闭 Supervisor 时 ， 需 要 释放 掉 当 前 Supervisor 所 占用 的 资源 ， 相 关 代码 如 下 : 


1 (shutdown [this] 

2 (log-message "Shutting down supervisor 
3 (reset! (:active supervisor) false) 

4 (cancel-timer (:timer supervisor)) 
5 
6 
7 


" 


(:supervisor-id supervisor)) 


(.shutdown event-manager) 

(.shutdown processes-event-manager) 

(.disconnect (:storm-cluster-state supervisor))) 
口 第 3 行将 当前 Supervisor 的 运行 状态 设置 为 false。 
O 第 4 行 关闭 计时 器 线程 。 
a 第 5 行 关闭 该 Supervisor 与 Nimbus 同 步 任务 的 线程 。 
口 第 6 行 关闭 该 Supervisor 管 理 Worker 进 程 的 线程 。 
口 第 7 行 释放 掉 与 ZooKeeper 的 连接 。 


8.5 重要 方法 介绍 
这 一 节 我 们 主要 介绍 Supervisor 中 几 个 重要 的 辅助 方法 ， 具 体 如 下 所 示 。 


口 launch-worker 


口 read-allocated-workers 
口 wait-for-worker-launch 


口 shutdown-worker 


口 dowload-storm-code 


8.5.1 launch-worker 


launch-worker 方 法 用 于 启动 Worker 进 程 。Storm 提 供 了 两 种 调用 模式 : Local 和 分 布 式 模式 。 
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在 LocalCluster 模 式 运 行 时 ， 就 使 用 Local 模 式 ; 而 在 实际 的 集群 中 运行 时 ， 则 使 用 分 布 式 模式 。 
下 面 分 别 介绍 一 下 这 两 种 模式 。 


1. 分 布 式 模式 


S 


在 分 布 式 模式 下 ， 主 要 通过 构造 JVM 命 令 行 参数 来 启动 Worker 进 程 ， 相 关 代 码 如 下 : 


(defmethod launch-worker 
:distributed [supervisor storm-id port worker-id] 
(let [conf (:conf supervisor) 
stormroot (supervisor-stormdist-root conf storm-id) 


storm-conf (read-supervisor-storm-conf conf storm-id) 
classpath (add-to-classpath (current-classpath) [stormjar]) 


1 
2 
3 
4 
5 stormjar (supervisor-stormjar-path stormroot) 
6 
7 
8 


childopts (.replaceAll (str (conf WORKER-CHILDOPTS) " " (storm-conf TOPOLOGY 


-WORKER-CHILDOPTS)) 


9 "%ID%" 

10 (str port)) 

11 jmx-port-offset (System/getProperty "storm.worker.jmxremote.port.offset") 

12 jmx-port (if (nil? jmx-port-offset) (+ port 1000) (+ port (Integer. jmx-port-offset))) 

13 logfilename (str "worker-" port ".log") 

14 command (str "java -server " childopts 

15 " -Djava.library.pathz" (conf JAVA-LIBRARY-PATH) 

16 " -Dlogfile.name-" logfilename 

17 " -Dstorm.home-" (System/getProperty "storm.home") 

18 " -Dstorm.log.dir-" (System/getProperty "storm.log.dir") 

19 " -Dlogback.configurationFile-" (System/getProperty "logback 
.configurationFile") 

20 " -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote. 
authenticate-false" 

21 " -Dcom.sun.management.jmxremote.sslefalse -Dcom.sun.management 
.jmxremote.port-" jmx-port 

22 " -cp " classpath " backtype.storm.daemon.worker " 

23 (java.net.URLEncoder/encode storm-id) " " (:assignment-id supervisor) 

24 " " port " " worker-id)] 

25 (log-message "Launching worker with command: " command) 

26 (launch-process command :environment ("LD LIBRARY PATH" (conf JAVA-LIBRARY-PATH)]) 

27 )) 


O 第 2 行 的 :distributed 表 明 这 是 分 布 式 模式 的 实现 ， 它 的 参数 有 如 下 4 个 。 
m supervisor: Supervisor-data 对 象 。 
m storm-id: 与 该 Worker 对 应 的 storm-id ( topology-id )。 
m port: 该 Worker 使 用 的 端口 号 。 
m worker-id: 该 Worker 的 id， 全 局 唯一 。 


O 第 4 行 调用 supervisor-stormdist-root 方 法 获取 Supervisor 机 器 上 的 stormroot 路 径 ， 它 的 
结构 是 : STORM-LOCAL-DIR/supervisor/stormdist/<storm-id>/。 

a 第 5 行 调用 supervisor-stormjar-path 方 法 获取 Supervisor 机 器 上 保存 jar 包 的 路 径 ， 它 的 结 
构 是 : STORM-LOCAL-DIR/supervisor/stormdist/<storm-id>/stormjar.jar。 

a 第 6 行 调用 read-supervisor-storm-conf 方 法 获取 启动 Worker 时 所 需 的 配置 信息 , 这 些 配置 
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信息 的 路 径 是 : STORM-LOCAL-DIR/supervisor/stormdist/<storm-id>/stormconf.ser. 

a 第 7 行 调用 add-to-classpath 方 法 将 第 $ 行 获取 的 stormjazr 路 径 添加 到 当前 的 class-path 路 
径 下 ， 并 将 其 保存 在 classpath 变 量 中 当前 的 classpath 路 径 是 指 调用 System.getProperty 
("java.class.path") 获 取 的 路 径 。 

口 第 8~10 行 将 NORKER-CHILDOPTS 和 TOPOLOGY-WORKER-CHILDOPTS 拼 接 起 来 ,并 将 其 中 的 %ID% 替 

换 为 真正 使 用 的 port， 最 后 将 替换 后 的 内 容 保存 在 childopts 变 量 中 。 

口 第 11 行 获取 设置 好 的 JMX 端 口 偏 移 量 。 

O 第 12 行 获取 使 用 的 JMX 端 口 。 如 果 第 11 行 获取 到 了 JMX 端 口 偏 移 量 (不 为 空 ) 那么 JMX 

使 用 的 端口 设置 为 port+jmx 偏 移 量 ， 否 则 将 其 设置 为 port+1000。JMX 端 口 通常 用 于 获取 
内 置 的 运行 统计 。 

口 第 13 行 获取 Worker 日 志文 件 的 名 字 ， 它 的 格式 是 : worker-<port>.log。 

口 第 14~24 行 构造 启动 Worker 的 命令 , 它 需 要 利用 前 面 构造 出 来 的 childopts、java.1ibrary. 
path, logfile, home, 、1og.dir、 日 志 的 配置 文件 、JMX 端 口 ，classpath 、storm-id 、 
supervisor-id、port 以 及 worker-id 等 信息 。 

口 第 26 行 调用 launch-process 方 法 ， 用 构造 好 的 命令 启动 Worker 进 程 。 

2. Local 模 式 

在 Local 模 式 下 ， 我 们 采用 线程 模拟 进程 的 方式 来 启动 Worker， 相 关 代 码 如 下 : 


1 (defmethod launch-worker 

2 :local [supervisor storm-id port worker-id] 

3 (let [conf (:conf supervisor) 

4 pid (uuid) 

5 worker (worker/mk-worker conf 

6 (:shared-context supervisor) 
7 storm-id 

8 (:assignment-id supervisor) 
9 port 

10 worker-id)] 

11 (psim/register-process pid worker) 

12 (swap! (:worker-thread-pids-atom supervisor) assoc worker-id pid) 


13  )) 


O 第 2 行 的 :local 表 明 这 段 代码 是 Local 模 式 的 实现 ， 其 参数 跟 分 布 式 模式 是 一 样 的 。 
a 第 4 行 构造 一 个 pid。Local 模 式 使 用 线程 来 模拟 进程 ， 所 以 它 使 用 process_simulator.clj 中 的 
方法 来 保存 当前 启动 的 Worker 信 息 。 这 个 pid 作 为 Worker 的 身份 标识 。 
口 第 5~10 行 调用 worker.clj 的 mk-worker 方 法 启动 Worker 线 程 ， 返 回 构 造 的 Worker 对 象 。 
口 第 11 行 将 Worker 对 象 注 册 到 process_simulator.clj 中 保存 。 
口 第 12 行 将 cworker-id，pid> 的 对 应 信息 更 新 到 supervisor-data 的 :worker-thread-pids-atom 
变量 中 。 
第 11 行 和 第 12 行 操作 的 目的 是 保存 当前 启动 Worker 的 对 应 信息 , 这 些 信息 在 后 面 关闭 Worker 
时 用 到 。 
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8.5.2 read-allocated-workers 


该 方法 用 于 获取 Worker 及 其 对 应 的 心跳 信息 , 并 根据 心跳 信息 判断 该 Worker 的 状态 , 相关 代 
人 码 如 下 : 


1 (defn read-allocated-workers 

2 [supervisor assigned-executors now] 

3 (let [conf (:conf supervisor) 

4 ^LocalState local-state (:local-state supervisor) 

5 id-»heartbeat (read-worker-heartbeats conf) 

6 approved-ids (set (keys (.get local-state LS-APPROVED-WORKERS) )) ] 

7 (into 

8 {} 

9 (dofor [[id hb] id->heartbeat] 

10 (let [state (cond 

11 (not hb) 

12 :not-started 

13 (or (not (contains? approved-ids id)) 

14 (not (matches-an-assignment? hb assigned-executors))) 

15 :disallowed 

16 (» (- now (:time-secs hb)) 

17 (conf SUPERVISOR-WORKER-TIMEOUT-SECS) ) 

18 :timed-out 

19 true 

20 :valid)] 

21 (log-debug "Worker " id " is " state ": " (pr-str hb) " at supervisor time 
-secs " now) 

2 [id [state hb]] 

23 )) 

24 ))) 


首先 介绍 该 方法 中 的 参数 。 
口 supervisor: supervisor-data 对 象 。 
C assigned-executors: 分 配给 该 Supervisor 的 任务 信息 , 是 一 个 <port, LocalAssignment> 集 合 。 
O now: 调用 该 方法 时 的 当前 时 间 。 
下 面 简 述 各 行 代码 的 作用 。 
口 第 3~4 行 获取 supervisor-data 中 的 配置 信息 以 及 local-state 对 象 。 
O 第 5 行 调用 read-worker-heartbeats 方 法 获取 <worker-id，heartbeat> 信 息 。 
a 第 6 行 获取 当前 local-state 中 保存 的 LS-APPROVED-WORKERS 人 信息， 获取 其 中 的 worker-id 集 
合作 为 approved-ids。 
a 第 7~23 行 对 第 5 行 返回 的 id->heartbeat 中 的 每 一 项 ， 根 据 其 心跳 信息 判断 当前 
如 果 没 有 心跳 信息 ， 设 置 状态 为 未 启动 。 
m 如 果 该 worker-id 不 在 approved-ids 列 表 中 , 或 者 assigned-executors 中 没有 分 配给 该 Worker 
的 任务 ,或 者 心跳 中 保存 的 storm-id 和 Executor 信 息 与 新 分 配 的 任务 (Local Assignment ) 
中 的 storm-id 和 Executor 信 息 不 一 致 ， 则 设置 Worker 状 态 为 非法 。 


PASS 
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m 如 果 最 新 的 心跳 时 间距 离 当 前 时 间 ( now ) 的 间隔 大 于 SUPERVISOR-WORKER-TIMEOUT-SECS 
( 默认 值 是 30 秒 )， 则 设置 Worker 状 态 为 超时 ; 
m 否则 设置 Worker 状 态 为 合法 。 
将 状态 信息 记录 在 state 变 量 中 ， 然 后 返回 一 个 <worker-id，<state，heartbeat>> 集 合 。 


8.5.3 wait-for-worker-launch 


该 方法 在 启动 Worker 时 被 调用 ， 它 会 保证 直到 Worker 成 功 启 动 起 来 后 才 返 回 ， 相 关 代 码 
WTF: 


1 (defn- wait-for-worker-launch [conf id start-time] 

2 (let [state (worker-state conf id)] 

3 (loop [] 

4 (let [hb (.get state LS-WORKER-HEARTBEAT) ] 

5 (when (and 

6 (not hb) 

7 (< 

8 (- (current-time-secs) start-time) 
9 (conf SUPERVISOR-WORKER-START-TIMEOUT-SECS) 
10 )) 

11 (log-message id " still hasn't started") 

12 (Time/sleep 500) 

13 (recur) 

14 ))) 

15 (when-not (.get state LS-WORKER-HEARTBEAT) 

16 (log-message "Worker " id " failed to start") 

17 )) 


首先 介绍 该 方法 的 3 个 参数 。 

O conf: 启动 Worker 时 需要 的 配置 信息 。 

口 id: Worker 的 id 信 息 。 

口 start-time: 启动 该 Worker 的 时 间 。 

下 面 简 述 各 行 代码 的 作用 。 

口 第 2 行 调 用 worker-state 方 法 获取 ( 或 创建 ) 该 Worker 的 local-state 对 象 ， 并 将 其 保存 到 

state 变 量 中 ， 它 的 路 径 为 : STORM-LOCAL-DIR/workers/<worker-id>/heatbeats/。 

a 第 3~14 行 是 一 个 循环 操作 ， 它 用 于 获取 state 中 保存 的 LS-WMORKER-HEARTBEAT 信 息 。 如 果 没 
有 获取 到 heartbeat 信 息 ， 且 当前 启动 时 间 还 小 于 SUPERVISOR-WORKER-START-TIMEOUT-SECS 

( 默认 值 是 120 秒 )， 则 认为 Worker 还 没 启动 起 来 ， 此 时 会 打印 日 志 ， 然 后 休眠 500 毫 秒 并 
继续 循环 操作 。 

a 第 15~16 行 判断 Worker 是 否 有 心跳 信息 ， 如 果 没 有 就 代表 启动 失败 ， 此 时 会 打印 日 志 。 
于 在 启动 时 间 超 过 SUPERVISOR-WORKER-START-TIMEOUT-SECS ( 默认 值 是 120 秒 ) 时 也 会 退出 
前 面 的 循环 操作 ， 这 一 步 则 确保 了 Worker 能 够 真正 地 启动 起 来 。 
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8.5.4 shutdown-worker 
该 方法 用 于 关闭 Worker 进 程 并 清理 Worker 的 本 地 文件 夹 ， 相 关 代 码 如 下 : 


1 (defn shutdown-worker [supervisor id] 
2 (log-message "Shutting down " (:supervisor-id supervisor) ":" id) 
3 (let [conf (:conf supervisor) 

4 pids (read-dir-contents (worker-pids-root conf id)) 

5 thread-pid (@(:worker-thread-pids-atom supervisor) id)] 
6 (when thread-pid 

7 (psim/kill-process thread-pid)) 

8 (doseq [pid pids] 


9 (ensure-process-killed! pid) 

10 (try 

11 (rmpath (worker-pid-path conf id pid)) 

12 (catch Exception e)) ;; on windows, the supervisor may still holds the lock on 
the worker directory 

13 ) 

14 (try-cleanup-worker conf id)) 


15 (log-message "Shut down 


首先 介绍 该 方法 的 两 个 参数 。 


口 supervisor: supervisor-data 对 象 。 


(:supervisor-id supervisor) ":" id)) 


ū id: worker-id. 


下 面 简 述 各 行 代码 的 作用 。 


pids/ 下 面 的 进程 号 信息 。 
O 第 5 行 根据 worker-id 从 supervisor-data 的 :worker-thread-pids-atom 中 获取 进程 号 
这 里 只 有 在 LocalCluster 模 式 时 才 会 有 进程 号 信息 。 


法 关闭 启动 的 Worker 线 程 。 


信 


a 第 8~13 行 对 当前 Worker 中 的 每 一 个 进程 号 调用 ensure-process-killed! 方法 确保 该 进程 


O 第 4 行 调用 read-dir-contents 方 法 获取 路 径 STORM-LOCAL-DIR/workers/<worker-id>/ 


自 
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Q 如 果 第 5 行 获取 到 了 进程 号 信息 ， 第 6~7 行 就 调用 process_simulator.clj 中 的 kill-process 方 


号 对 应 的 进程 已 经 被 杀 掉 ， 然 后 尝试 删除 该 进程 号 的 本 地 路 径 STORM-LOCAL-DIR/ 


workers/<worker-id>/pids/<pid>/。 


口 第 14 行 尝试 清理 Worker 的 本 地 目录 : 首先 删除 STORM-LOCAL-DIR/workers/<worker-id> 
/heartbeats/ 目 录 , 接着 删除 STORM-LOCAL-DIR/workers/<worker-id>/pids/ 目 录 , 最 后 删除 


STORM-LOCAL-DIR/workers/<worker-id>/ 目 录 。 


8.5.5 download-storm-code 


这 个 方法 用 于 从 Nimbus 下 载 与 分 配给 当前 Supervisor 的 任务 相对 应 的 Topology 信 息 。 跟 
launch-worker 方 法 类 似 ， 该 方法 也 有 两 种 模式 一 一 Local 模 式 和 分 布 式 模 式 ， 下 面 我 们 分 别 给 予 


介绍 。 
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1. 分 布 式 模式 
分 布 式 模式 使 用 Nimbus 提 供 的 下 载 方法 来 获取 所 需 的 Topology 信 息 ， 相 关 代码 如 下 : 


1 (defmethod download-storm-code 

2 :distributed [conf storm-id master-code-dir] 

3 ;; Downloading to permanent location is atomic 

4 (let [tmproot (str (supervisor-tmp-dir conf) file-path-separator (uuid)) 
5 stormroot (supervisor-stormdist-root conf storm-id)] 

6 (FileUtils/forceMkdir (File. tmproot)) 

7 

8 


(Utils/downloadFromMaster conf (master-stormjar-path master-code-dir) (supervisor 
-stormjar-path tmproot)) 


9 (Utils/downloadFromMaster conf (master-stormcode-path master-code-dir) 
(supervisor-stormcode-path tmproot)) 

10 (Utils/downloadFromMaster conf (master-stormconf-path master-code-dir) 
(supervisor-stormconf-path tmproot)) 

11 (extract-dir-from-jar (supervisor-stormjar-path tmproot) RESOURCES-SUBDIR tmproot) 

12 (FileUtils/moveDirectory (File. tmproot) (File. stormroot)) 

13  )) 


口 第 2 行 的 :distributed 表 明 这 是 分 布 式 模式 的 实现 ， 它 的 参数 有 如 下 3 个 。 
m conf: Supervisor 使 用 的 配置 信息 。 
m storm-id: 要 下 载 的 Topology 的 id。 
m master-code-dir: Nimbus 机 器 上 保存 该 Topology 信 息 的 文件 夹 。 
a 第 4 行 构造 一 个 临时 的 root 文 件 夹 来 存放 新 下 载 的 Topology 信 息 ， 它 的 路 径 是 STORML- 
LOCAL-DIR/supervisor/tmp/<uuid>/。 
a 第 5 行 创建 真正 存储 Topology 下 载 信息 的 文件 夹 ， 其 路 径 是 STORM-LOCAL-DIR/supervisor/ 
stormdist/<storm-id>/。 
a 第 6 行 创 建 第 4 行 的 临时 文件 夹 。 
口 第 8 行将 stormjarjar 文 件 下 载 到 临时 文件 夹 中 。 
口 第 9 行将 stormcode.ser 文 件 下 载 到 临时 文件 夹 中 。 
口 第 10 行 将 stormconf.ser 文 件 下 载 到 临时 文件 夹 中 。 
a 第 11 行 调用 extract-dir-from-jar 方 法 将 stormjar.jar 中 的 资源 文件 夹 提取 出 来 放 到 临时 文 
件 夹 中 。 
口 第 12 行 将 临时 文件 夹 里 的 内 容 全 部 移 到 真正 的 存储 目录 中 。 
2. Local 模 式 
在 Local 模 式 下 ， 我 们 将 从 本 机 复制 所 需 的 Topology 信 息 ， 相 关 代 码 如 下 : 


1 (defmethod download-storm-code 

2 :local [conf storm-id master-code-dir] 

3 (let [stormroot (supervisor-stormdist-root conf storm-id)] 

4 (FileUtils/copyDirectory (File. master-code-dir) (File. stormroot)) 
5 (let [classloader (.getContextClassLoader (Thread/currentThread)) 

6 resources-jar (resources-jar) 
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7 url (.getResource classloader RESOURCES-SUBDIR) 

8 target-dir (str stormroot file-path-separator RESOURCES-SUBDIR)] 

9 (cond 

10 resources-jar 

11 (do 

12 (log-message "Extracting resources from jar at " resources-jar " to " 
target-dir) 

13 (extract-dir-from-jar resources-jar RESOURCES-SUBDIR stormroot)) 

14 url 

15 (do 

16 (log-message "Copying resources at " (str url) " to " target-dir) 

17 (FileUtils/copyDirectory (File. (.getFile url)) (File. target-dir)) 

18 )) 

19 ))) 


a 第 2 行 的 :local 表 明 这 是 Local 模 式 的 实现 ， 它 的 参数 跟 分 布 式 模式 的 参数 一 样 。 

a 第 3 行 创建 存储 该 Topology 信 息 的 文件 夹 作为 stormroot, 它 的 路 径 是 STORM-LOCAL-DIR 
/supervisor/stormdist/<storm-1id>/。 

a 第 4 行 复制 master-code-dir 中 的 所 有 内 容 到 stormroot 下。 

a 第 5 行 获取 当前 线程 的 类 加 载 器 对 象 。 

口 第 6 行 调用 resources-jar 方 法 从 java.class.path 的 系统 参数 中 获取 第 一 个 包含 resources 
文件 夹 的 jar 包 。 

a 第 7 行 调用 类 加 载 器 的 getResource 方 法 获取 资源 文件 夹 的 地 址 。 

口 第 8 行 构造 路 径 STORM-LOCAL-DIR/supervisor/stormdist/<storm-id>/resources/ 作 为 target-dir。 
a 第 9~18 行 判断 怎样 提取 resources 文 件 夹 。 如 果 第 6 行 获 取 到 jar 包 (不 为 空 )， 那么 就 调用 
extract-dir-from-jar 方 法 将 resources 文 件 夹 提 取出 来 并 复制 到 STORM-LOCAL-DIR/supervisor/ 
stormdist/<storm-id>/resources/ 目 录 下 面 。 如 果 没 有 获得 包含 资源 文件 夹 的 jar 包 并 日 第 7 行 
获得 的 资源 文件 夹 的 地 址 不 为 空 ， 就 将 该 地 址 下 对 应 的 文件 复制 到 目录 中 。 这 两 种 方式 
对 应 了 在 Local 模 式 中 以 jar 包 方式 运行 和 以 文件 夹 方式 运行 。 
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Storm 中 的 Worker 是 实际 执行 Topology 的 进程 , 它 由 Supervisor 启 动 , 从 ZooKeeper 中 获取 分 配 
到 自身 的 所 有 Executor 并 启动 这 些 Executor 来 执行 。 


9.1 Worker 中 的 数据 


Worker 通 过 worker-data 方 法 定义 了 一 个 包含 很 多 共享 数据 的 映射 集合 ， 这 是 一 个 很 重要 的 
数据 结构 ，Worker 中 的 很 多 方法 都 依赖 它 。 表 9-1 详 细 描述 了 也 这 个 集合 的 信息 。 


表 9-1 Worker 数 据 


:cluster-state 


:storm-cluster-state 


:storm-active-atom 


:executors 


:task-ids 


:storm-conf 


cluster/mk-distributed-cluster-state conf 


(cluster/mk-storm-cluster-state 
cluster-state) 


(atom false) 


read-worker-executors 
storm-conf 
storm-cluster-state 
storm-id assignment-id port 


(->> receive-queue-map keys (map int) 
sort) 


(read-supervisor-storm-conf conf storm-id) 


数据 名 称 获取 方法 fa xh 
:conf 参数 传人 配置 项 
:mq-context msg-loader/mk-zmq-context ZMQ 的 运行 上 下 文 
:storm-id 参数 传人 StormID 
:assignment-id 参数 传人 任务 分 配 id， 即 SupervisorId 
:port 参数 传人 Worker 的 端口 号 
:worker-id 参数 传人 Workerld 


Cluster 的 状态 ， 用 于 访问 ZooKeeper 
Cluster 中 Topology 的 状态 。 通 过 访问 
ZooKeeper 来 获取 cluster 中 Topology 的 
元 数据 并 将 其 存储 于 : :storm-cluster- 
state 
Topology 是 否 活 跃 的 标志 

调用 read-worker-executors 来 获得 分 
配 到 该 Worker 上 的 所 有 Executor 


Worker 中 含有 的 TaskId 集 合 ， 根 据 
Executor 计 算得 到 ,后 面 将 进一步 讨论 
获取 Storm 的 配置 项 ， 后 面 将 进一步 


讨论 
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数据 名 称 获取 方法 fe xk 
: topology (read-supervisor-topology conf storm-id) ”获取 JP X. Topologyfr ll, Jali 


:system-topology 


:heartbeat-timer 
:refresh-connections-timer 
:refresh-active-timer 
:executor-heartbeat-timer 


:user-timer 


:task-component 


:component-»stream-»fields 


:component-»sorted-tasks 


:endpoint-socket-lock 


:cached-node+port->socket 


:cached-task->node+port 


:transfer-queue 


:executor-receive-queue-map 


:short-executor-receive-queue-map 


:task-»short-executor 
:suicide-fn 

:uptime 
:default-shared-resources 


:user-shared-resources 


(system-topology! storm-conf topology) 


(mk-halting-timer) 
(mk-halting-timer) 
(mk-halting-timer) 
(mk-halting-timer) 


(mk-halting-timer) 


storm-task-info 


component-»stream-»fields 


-»» (:task-»component <>) reverse-map 
(map-val sort) 


(mk-rw-lock) 


atom () 


atom {} 


transfer-queue 


executor-receive-queue-map 


(map-key first executor-receive-queue- 
map) 


参数 传人 

(mk-suicide-fn conf) 
(uptime-computer) 
(mk-default-resources <>) 


(mk-user-resources <>) 


将 进一步 讨论 


在 用 户 定义 的 Topology 的 基础 上 添加 
系统 组 件 ， 例 如 Acker Bolt, 


将 进一步 讨论 

Worker 心 跳 计时 器 
ZMQ 连 接 维护 计时 器 
获取 Topology 状 态 的 计时 器 
Executor OBEH AE 


后 面 


Executor 内 部 的 定时 器 ，Spout 类 型 的 


Executor 会 定期 向 自身 发 送 消息 ， 
息 执 行 特 


后 该 Executor 根 据 收 到 的 消 ， 


定 的 操作 ， 比 如 清理 消息 发 送 缓存 等 


TaskId£l|ComponentIdÉH HRA 


组 件 到 流 以 及 到 流 的 所 有 字段 的 映 


射 关 系 


缓存 ， 详 情 可 参见 第 5 章 


Component 到 Task 的 映射 关系 


用 于 更 新 ZMQ 连 接 信 息 的 锁 


消息 目标 端 node+port 到 ZMQ Socket 


taskId 到 其 所 在 的 node+port 缓 存 ， 详 


情 参见 第 5 章 


Worker 的 消息 发 送 队 列 。Executor 向 
外 发 送 消息 时 先 将 其 放 入 该 队列 ,再 
Worker 通 过 ZMQ 发 送出 去 


Worker 的 消息 接收 队列 集合 ， 


Executor 对 应 其 中 一 个 队列 


Eit 


个 


StartTaskId 到 接收 消息 队列 的 映射 


TaskId 到 StartTaskId 的 映射 关系 
自杀 函数 

Worker 的 启动 时 间 
默认 的 共享 资源 

用 户 资 源 ， 目 前 没有 用 到 


9.2 Worker 中 的 计时 器 157 


(5X) 
数据 名 称 获取 方法 Ho Ë 

:transfer-local-fn mk-transfer-local-fn 若 目 标 Task 位 于 同一 Worker 时 的 消 
息 发 送 方法 ,将 直接 发 送 至 目标 
Task/Executor 的 接收 消息 队列 ， 不 需 
要 串 行 化 ， 具 有 较 高 效率 

:transfer-fn mk-transfer-fn Worker 的 消息 发 送 函 数 。 当 目标 Task 
属于 同一 个 Worker 时 ,调用 transfer- 
local-fn 其 他 情况 则 发 送 :transfer- 
queue 中 的 消息 到 ZMQ 


9.2 Worker 中 的 计时 器 


每 个 计时 需 都 对 应 着 一 个 Java 线 程 ，Worker 中 使 用 计时 器 进行 心跳 保持 以 及 获取 元 数据 的 更 
新 信息 。 


9.2.1 Worker 的 心跳 


do-heartbeat 函数 用 于 产生 Worker 的 心跳 信息 ， 这 些 心跳 信息 被 写 人 本 地 文件 系统 中 。 
Supervisor 会 读 取 这 些 心 跳 信息 以 判断 Worker 的 状态 ， 然 后 决定 是 否 需要 重启 Worker， 相 关 代 码 
如 下 : 


(defn do-heartbeat [worker] 
(let [conf (:conf worker) 
hb (WorkerHeartbeat. 
(current-time-secs) 
(:storm-id worker) 
(:executors worker) 
(:port worker))] 
(log-debug "Doing heartbeat " (pr-str hb)) 
;; do the local-file-system heartbeat. 
(.put (worker-state conf (:worker-id worker)) 
LS-WORKER -HEARTBEAT 
hb) 
) 


从 该 函数 可 以 看 出 Worker 的 心跳 包含 如 下 信息 . 
O current-time-secs: 当前 时 间 。 
口 :storm-id: 即 TopologyId。 
口 :executors: Worker 中 包含 的 Executor 列 表 。 
口 :port: 与 Worker 对 应 的 端口 号 。 
Worker-state 方 法 会 创建 一 个 Localstate 对 象 ， 并 调用 该 对 象 的 put 方 法 将 Worker 的 心跳 信息 
存储 到 本 地 的 文件 系统 中 , 对 应 路 径 是 STORM-LOCAL-DIR/workers/<workerId>/heartbeats, 存储 
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时 使 用 的 键 为 常量 LS-WORKER-HEARTBEAT。 Supervisor 通 过 读 取 Worker 的 心跳 信息 来 判断 该 Worker 
是 否 在 正常 运行 。 


图 9-1 展 示 了 Worker 的 heartbeat 目 录 下 的 文件 ， 文 件 名 为 当前 的 时 间 戳 。 
L.] 1385390458287 25 File 2 KB 
_| 1385390458287.version 25 ERSION File 0 KB 
|_| 1385390459288 25/2013 6 File 2 KB 
|_| 1385390459288.version 25/2013 6:41 A ERSION File 0 KB 
|_| 1385390460290 25/20 File 2 KB 
|_| 1385390460290.version 25 ERSION File 0 KB 
|_| 1385390461294 25 File 2KB 
|} 1385390461294.version 25/2 ERSION File KB 
图 9-1 Worker 的 heartbeat 目 录 


Storm 采 用 :heartbeat-timer 计 时 器 来 持续 地 发 送 心 跳 信 息 ， 每 次 发 送 的 时 间 间 隔 由 
WORKER-HEARTBEAT-FREQUENCY-SECS 来 设 定 ， 默 认 值 为 1 秒 ， 相 关 代 码 如 下 : 


. (schedule-recurring (:heartbeat-timer worker) 0 (conf WORKER-HEARTBEAT-FREQUENCY-SECS) 
heartbeat-fn) 


9.2.2 “Executor 的 心跳 


Worker 的 心跳 与 不 同 , Executor 的 心跳 信息 需要 直接 发 送 到 ZooKeeper 中 保存 。 该 心跳 信息 主 
要 保存 了 Executor 中 Task 的 运行 统计 ，Nimbus 利 用 这 些 心跳 信息 判断 Executor 是 否 处 于 活跃 状态 
并 且 还 会 在 Storm UI 上 显示 这 些 运行 统计 。 

do-executor-heattbeats 函 数 用 来 发 送 一 次 心跳 信息 ， 相 关 代码 如 下 : 


1 (defnk do-executor-heartbeats [worker :executors nil] 

2 33 Stats is how we know what executors are assigned to this worker 

3 (let [stats (if-not executors 

4 (into {} (map (fn [e] {e nil}) (:executors worker))) 

5 (-»» executors 

6 (map (fn [e] ((executor/get-executor-id e) (executor/render-stats e)})) 
7 (apply merge))) 

8 zk-hb {:storm-id (:storm-id worker) 

9 :executor-stats stats 


10 :uptime ((:uptime worker)) 

11 :time-secs (current-time-secs) 

12 )] 

13 33 do the zookeeper heartbeat 

14 (.worker-heartbeat! (:storm-cluster-state worker) (:storm-id worker) (:assignment-id 


worker) (:port worker) zk-hb) 
15 )) 


O 第 6 行 通过 executor/render-stats 方 法 来 获得 Executor 的 运行 统计 信息 ， 例 如 发 送 消息 的 
数目 等 
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O 第 8~12 行 构建 Executor 的 心跳 对 象 ， 包 含 如 下 信息 。 
m :storm-id: 即 TopologyId。 
m :executor-stats: 该 Worker 中 Executor 的 运行 统计 ， 具 体 为 对 每 一 个 Task 的 统计 。 
m :uptime: Worker 的 启动 时 间 。 
m :time-secs: 当前 时 间 。 
O 第 14 行 调用 :storm-cluster-state 的 worker-heartbeat ! 方 法 存储 心跳 信息 。 在 ZooKeeper 
中 的 默认 路 径 为 : 


/storm/workerbeats/«storm-id» /<node-port> 


同样 地 ，Worker 使 用 :executor-heartbeat-timer 计 时 器 线程 来 发 送 Executor 的 心跳 信息 ， 
默认 为 3 秒 钟 更 新 一 次 : 


_ (schedule-recurring (:executor-heartbeat-timer worker) 0 (conf TASK-HEARTBEAT-FREQUENCY-SECS) 
#(do-executor-heartbeats worker :executors @executors) ) 


9.2.3 ”Worker 中 对 ZMQ 连 接 的 维护 


在 进程 间 ，Storm 利 用 ZMQ 来 发 送 和 接收 消息 ， 并 采用 端 到 端的 方式 完成 消息 传输 。Worker 
会 根据 Topology 的 定义 以 及 分 配 到 自身 的 任务 情况 ， 计 算出 自己 发 出 的 消息 将 被 哪些 Task 接 收 。 
基于 Topology 的 这 一 任务 分 配 信息 ，Worker 可 以 获悉 目标 Task 所 在 的 机 器 及 端口 号 。 虽 然 Worker 
会 创建 并 缓存 这 些 连 接 , 但 由 于 Worker 上 的 分 配 任务 可 能 被 调整 , 因此 Worker 需 要 定时 地 更 新 这 
些 连 接 信 息 。 例 如 ， 若 新 增 目标 机 器 ， 则 要 增加 连接 并 且 关闭 不 需要 的 连接 。 

mk-refresh-connections 函 数 用 来 更 新 这 些 ZMQ 连 接 信息 ， 相 关 代码 如 下 : 


1 (defn mk-refresh-connections [worker] 

2 (let [outbound-tasks (worker-outbound-tasks worker) 

3 conf (:conf worker) 

4 storm-cluster-state (:storm-cluster-state worker) 

5 storm-id (:storm-id worker)] 

6 (fn this 

7 

8 (this (fn [& ignored] (schedule (:refresh-connections-timer worker) O this)))) 
97 ([callback] 

10 (let [assignment (.assignment-info storm-cluster-state storm-id callback) 

11 my-assignment (-» assignment 

12 :executor->node+port 

13 to-task->node+port 

14 (select-keys outbound-tasks) 

15 (#(map-val endpoint->string %))) 

16 33 we dont need a connection for the local tasks anymore 

17 needed-assignment (->> my-assignment 

18 (filter-key (complement (-> worker :task-ids set)))) 
19 needed-connections (-> needed-assignment vals set) 


20 needed-tasks (-> needed-assignment keys) 
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21 

22 current-connections (set (keys @(:cached-node+port->socket worker))) 
23 new-connections (set/difference needed-connections current-connections) 
24 remove-connections (set/difference current-connections needed-connections)] 
25 (swap! (:cached-node+port->socket worker) 

26 #(HashMap. (merge (into (j %1) %2)) 

27 (into {} 

28 (dofor [endpoint-str new-connections 

29 :let [[node port] (string-»endpoint endpoint-str)]] 

30 [endpoint-str 

31 (msg/connect 

32 (:mq-context worker) 

33 storm-id 

34 ((:node-»host assignment) node) 

35 port) 

36 ] 

37 

38 (write-locked (:endpoint-socket-lock worker) 

39 (reset! (:cached-task->node+port worker) 

40 (HashMap. my-assignment) )) 

41 (doseq [endpoint remove-connections] 

42 (.close (get @(:cached-nodetport->socket worker) endpoint))) 

43 (apply swap! 

44 (:cached-node+port->socket worker) 

45 #(HashMap. (apply dissoc (into {} %1) %&)) 

46 remove-connections) 

47 

48 (let [missing-tasks (->> needed-tasks 

49 (filter (complement my-assignment)))] 

50 (when-not (empty? missing-tasks) 

51 (log-warn "Missing assignment for following tasks: " (pr-str missing-tasks)) 
52 ))))))) 


数 接收 数据 的 TaskId 集 合 。 


口 第 2 行 通过 调用 worker-outbound-tasks 函 数 得 到 outbound-tasks， 该 函数 返回 从 Worker 参 


O 第 6 行 定 义 了 this 函 数 。 在 Clojure 中 ，this 只 是 普通 的 名 字 。 


口 第 7~8 行 定义 函数 的 第 一 个 重 载 ， 该 重 载 定义 了 一 
的 :refresh-connections-timer 定 时 器 上 注册 自己 。 
口 第 9 行 开 始 定 义 一 个 带 有 callback 参 数 的 回调 函数 。 


的 Socket 连 接 是 非常 好 的 时 机 。ZooKeeper 中 的 Watcher 回 调 函 


个 回调 函数 ， 它 将 在 Worker 


a 第 10 行 调用 storm-cluster-state 的 assignment 函 数 获取 与 storzm-id 对 应 的 Topology 的 任务 分 
配 。 注 意 在 将 callback 作 为 回调 函数 时 ， 该 函数 会 被 注册 到 ZooKeeper 的 某 个 节点 上 充当 
Watcher 表 数 ， 即 当 ZooKeeper 中 的 节点 发 生变 化 时 ， 客 户 端 


便 会 收 到 通知 ， 此 时 更 新 Worker 
数 在 执行 之 后 需要 重新 注册 。 


a 第 11~15 行 获取 接收 该 Worker 消 息 的 节点 集合 。:executor->node+port 用 来 存储 从 Executor 
到 node+port 的 映射 关系 ; 而 to-task->node+port 函 数 则 会 根据 Executor 中 的 TaskId 集 合 来 
构建 从 TaskId 到 node+port 的 映射 关系 ; 接 下 来 利用 select-keys 函 数 及 outbound-tasks 集 合 

进行 过 滤 ， 得 到 从 该 Worker 接 收 消息 的 TaskId 到 node+port 的 映射 关系 ; 最 后 调用 map-val 
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及 endpoint->string 函 数 获 取 node+port 的 字符 串 表 示 。 最 终结 果 为 一 个 从 TaskId 到 
node+port 的 哈 希 表 。 

口 第 17~18 行 对 my-assignment 进 行 过 滤 ， 移 除 所 有 属于 该 Worker 的 TaskId。 这 里 需 注意 属于 

同一 Worker 的 Task 之 间 不 需要 利用 ZMQ 来 完成 通信 。 

O 在 第 19~20 行 中 , needed-connections 为 目标 Worker 的 节点 集合 , 而 needed-tasks 则 代表 目 

标 节 点 上 的 所 有 TaskId。 

O 第 22 行 获取 在 Worker 节 点 上 缓存 的 从 node+port 到 ZMQ Socket 的 哈 希 表 的 所 有 键 列 表 ， 并 

将 其 保存 到 current-connections 变 量 中 。 

O 第 23~24 行 判断 哪些 连接 需要 新 建 ， 哪 些 连 接 可 以 关闭 。 

O 第 25~37 行 调用 msg/connect 方 法 ， 根 据 new-connections 中 的 node+port 创 建新 的 连接 ， 并 

放 和 集合 current-connections 中 。 

口 第 38~40 行 将 cached-task->node+port 更 新 为 my-assignment 变 量 。 

口 第 41~46 行 调用 需要 删除 的 Socket 的 close 方 法 ， 将 这 些 Socket 从 :cached-node+port 变 量 中 

移 除 。 

口 第 48~52 行 对 异常 情况 进行 处 理 ， 基 本 上 不 应 该 发 生 ， 若 发 生 ， 可 能 会 重新 分 配 任 务 。 例 
如 ， 若 属于 当前 Worker 的 任务 被 分 配 到 其 他 Worker 上 ， 由 于 该 函数 会 被 计时 器 线程 反复 
调用 ， 故 此 处 则 只 会 打印 警告 信息 。 

最 后 来 看 一 下 这 些 函数 的 调用 时 机 ， 相 关 代 码 如 下 : 


1 :refresh-connections-timer (mk-halting-timer) 

2 refresh-connections (mk-refresh-connections worker) 

3 _ (refresh-connections nil) 

4 (schedule-recurring (:refresh-connections-timer worker) 0 (conf TASK-REFRESH-POLL-SECS) 

refresh-connections) 

a 第 1 行 创建 一 个 定时 器 。mk-halting-timer 创 建 了 一 个 计时 器 ， 该 计时 器 会 在 异常 发 生 时 

抛 出 异常 并 退出 进程 。 该 行 代码 会 在 创建 Worker 数 据 时 调用 。 

口 第 2~4 行 代码 在 mk-worker 函 数 中 被 调用 。 第 2 行 创建 一 个 用 于 更 新 连接 的 函数 ， 然 后 立即 
执行 refresh-connections 函 数 更 新 ZMQ 消 息 。 第 4 行将 不 断 执行 该 函数 ， 执 行 间隔 为 
TASK-REFRESH-POLL-SECS， 默 认为 10 秒 钟 。 

从 代码 中 可 以 看 出 ，Worker 通 过 两 种 机 制 来 保证 连接 的 可 靠 性 。 一 是 在 ZooKeeper 中 注册 

Watcher 回 调 通知 方法 ,这 种 方式 并 不 一 定 可 靠 ,例如 若 与 ZooKeeper 的 连接 丢失 , 则 注册 的 Watcher 

回调 方法 将 失效 。 二 是 采用 定时 需 的 方式 来 定期 执行 该 函数 。 


9.2.4 从 ZooKeeper 获 取 Topology 的 活跃 情 ; 


Worker 需 要 获知 其 执行 的 Topology 的 状态 ， 例 如 ， 若 用 户 已 经 把 Topology 的 状态 由 活跃 变 为 
非 活 跃 ，Spout 应 停止 向 外 发 送 消息 。 
refresh-storm-active 函 数 用 于 获取 Topology 的 状态 信息 ， 相 关 代 人 码 如 下 : 
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1 (defn refresh-storm-active 


2 ([worker] 


3 (refresh-storm-active worker (fn [& ignored] (schedule (:refresh-active-timer worker) 
O (partial refresh-storm-active worker))))) 


4 ([worker callback] 
5 

6 (reset! 

7 

8 

9 )) 

10 )) 


(:storm-active-atom worker) 
(= :active (-» base :status :type)) 


(let [base (.storm-base (:storm-cluster-state worker) (:storm-id worker) callback) ] 


O 第 2~4 行 定义 了 refresh-storm-active 的 一 个 重 载 方 法 ， 它 默认 提供 了 一 个 匿名 函数 作为 
callback 人 参数 ， 该 匿名 函数 被 注册 为 ZooKeeper 中 getData 方 法 的 Watcher 回 调 方法 。 当 
ZooKeeper 中 的 数据 发 生变 化 时 ， 该 方法 将 被 回调 ， 于 是 Topology 的 状态 就 会 在 Worker 中 


被 及 时 更 新 。 


refresh-storm-activ 


active-atom 变 量 中 。 


9.2.5 小结 


e 国 数 还 会 通过 :refresh-active-timer 计 时 器 完成 定期 调用 ， 默 认 的 
时 间 间 隔 为 10 秒 钟 ， 调 用 代码 如 下 : 


(schedule-recurring (:refresh-active-timer worker) 0 (conf TASK-REFRESH-POLL-SECS) (partial 
refresh-storm-active worker)) 


将 错误 记录 到 日 志 中 并 退出 JVM， 相 关 代码 如 下 : 


(defn mk-halting-timer [] 


(mk-timer :kill-fn (fn [t] 


(log-error t "Error when processing event") 


O 第 5 行 调用 :storm-cluster-state 的 storm-base 方 法 获得 Topology 的 基础 信息 。 
口 第 7 行 判 断 该 Topology 是 否 处 于 活跃 状态 ( :active )， 并 将 判断 结果 存储 于 :storm- 


mk-halting-timer 函 数 用 于 调用 mk-timer 函 数 来 创建 一 个 计时 器 ， 该 计时 器 会 在 遇 到 错误 时 


(halt-process! 20 "Error when processing an event") 


)) 


对 Worker 中 用 到 的 计时 需 的 总 结 如 表 9-2 所 示 。 
表 9-2 ”Worker 中 的 计时 器 线程 


计 时 器 回调 方法 作 用 
:heartbeat-timer do-heartbeat Worker 本 地 的 心跳 
:executor-heartbeat-timer do-executor-heartbeats Worker 中 Executor 的 心跳 
:refresh-connections-timer refresh-connections 更 新 ZMQ 的 连接 信息 
:refresh-active-timer refresh-storm-active 判断 Topology 是 否 为 活跃 状态 
:user-timer 在 Spout 类 型 的 Executor 中 使 用 ”在 Executor 中 用 于 向 SYSTEM_TICK_STREAM 发 送 Tick 消 息 
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9.3 创建 Worker 


mk-worker 函 数 用 于 创建 Worker 进 程 , 其 主要 工作 包括 启动 相应 的 计时 器 、 创 建 Worker 中 对 应 
的 Executor， 以 及 启动 接收 线程 来 接收 消息 ， 相 关 代 码 如 下 : 


1 (defserverfn mk-worker [conf shared-mq-context storm-id assignment-id port worker-id] 

(log-message "Launching worker for " storm-id " on " assignment-id ":" port " with id 
" worker-id 

3 and conf " conf) 

4 (if-not (local-mode? conf) 

5 (redirect-stdio-to-slf4j!)) 

6 33 because in local mode, its not a separate 

7 

8 

9 


N 


n" 


33 process. supervisor will register it in this case 
(when (= :distributed (cluster-mode conf)) 
(touch (worker-pid-path conf worker-id (process-pid)))) 
10 (let [worker (worker-data conf shared-mq-context storm-id assignment-id port worker-id) 


11 heartbeat-fn #(do-heartbeat worker) 
12 33 do this here so that the worker process dies if this fails 
13 ;; it's important that worker heartbeat to supervisor ASAP when launching so 
that the supervisor knows it's running (and can move on) 
14 _ (heartbeat-fn) 
15 
16 33 heartbeat immediately to nimbus so that it knows that the worker has been started 
17 _ (do-executor-heartbeats worker) 
18 
19 
20 executors (atom nil) 
21 3; launch heartbeat threads immediately so that slow-loading tasks don't 
cause the worker to timeout 
22 33 to the supervisor 
23 . (schedule-recurring (:heartbeat-timer worker) 0 (conf WORKER-HEARTBEAT 
-FREQUENCY-SECS) heartbeat-fn) 
24 . (schedule-recurring (:executor-heartbeat-timer worker) 0 (conf TASK-HEARTBEAT 
-FREQUENCY-SECS) #(do-executor-heartbeats worker :executors @executors)) 
25 
26 
27 refresh-connections (mk-refresh-connections worker) 
28 
29 _ (refresh-connections nil) 
30 _ (refresh-storm-active worker nil) 
31 
32 _ (reset! executors (dofor [e (:executors worker)] (executor/mk-executor worker e))) 
33 receive-thread-shutdown (launch-receive-thread worker) 
34 
35 transfer-tuples (mk-transfer-tuples-handler worker) 
36 
37 transfer-thread (disruptor/consume-loop* (:transfer-queue worker) transfer-tuples) 
38 shutdown* (单独 讨论 ) 
39 ret (reify 
40 Shutdownable 
41 (shutdown 


42 [this] 
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43 (shutdown*)) 

44 DaemonCommon 

45 (waiting? [this] 

46 (and 

47 (timer-waiting? (:heartbeat-timer worker)) 

48 (timer-waiting? (:refresh-connections-timer worker)) 
49 (timer-waiting? (:refresh-active-timer worker)) 

50 (timer-waiting? (:executor-heartbeat-timer worker)) 
51 (timer-waiting? (:user-timer worker)) 

52 )) 

53 )] 

54 


55  (schedule-recurring (:refresh-connections-timer worker) 0 (conf TASK-REFRESH-POLL-SECS) 
refresh-connections) 

56 (schedule-recurring (:refresh-active-timer worker) 0 (conf TASK-REFRESH-POLL-SECS) (partial 
refresh-storm-active worker)) 


57 

58  (log-message "Worker has topology config " (:storm-conf worker)) 

59  (log-message "Worker " worker-id " for storm " storm-id " on " assignment-id ":" port " 
has finished loading") 

60 ret 

61  )) 


O 在 第 4~5$ 行 代码 中 ， 若 为 分 布 式 模式 ， 则 将 打印 到 控制 台 的 信息 打 到 日 志 里 面 。 

O 在 第 8~9 行 代码 中 ， 若 为 分 布 式 模式 ， 则 将 与 Worker 对 应 的 进程 ID 放 到 pids 目 录 下 ， 并 创 

建 以 进程 ID 作 为 文件 名 的 空 文件 。Supervisor 在 关闭 Worker 时 会 尝试 关闭 pids 目 录 下 面 所 
有 与 进程 ID 相对 应 的 进程 。Worker 创 建 的 子 进程 也 应 遵循 这 样 的 规则 。 在 Storm 中 ， 由 于 
任务 会 被 重新 调度 ， 因 此 正在 执行 的 Worker 也 可 能 被 关闭 。 

a 第 11~24 行 分 别 启动 Worker 以 及 Executor 的 心跳 计时 器 线程 。 这 里 都 是 预先 调用 一 次 ， 
以 确保 第 一 次 的 心跳 信息 可 被 快速 发 送出 去 , 然后 启动 计时 器 线程 来 完成 周期 性 的 心跳 
更 新 。 

a 第 27~30 行 创建 用 于 完成 ZCMQ 连 接 更 新 的 计时 器 线程 。 

a 第 33 行 启动 消息 的 接收 线程 ，receive-thread-shutdown 为 该 线程 的 关闭 函数 。 

a 第 35~37 行 启动 消息 队列 的 发 送 线程 


o 


9.4 关闭 Worker 


理解 Worker 的 关闭 函数 有 利于 进一步 理解 Worker 中 启动 的 线程 及 资源 , 关闭 Worker 的 函数 的 
代码 如 下 : 


1 fn [] 

2 (log-message "Shutting down worker " storm-id " " assignment-id " " port) 
3 (doseq [[_ socket] @(:cached-node+port->socket worker) ] 

4 33 this will do best effort flushing since the linger period 

5 33 was set on creation 

6 (.close socket) ) 
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7 (log-message "Shutting down receive thread") 
8 (receive-thread-shutdown) 

9 (log-message "Shut down receive thread") 

10 (log-message "Terminating zmq context") 

11 (log-message "Shutting down executors") 


12 (doseq [executor @executors] (.shutdown executor) ) 

13 (log-message "Shut down executors") 

14 

15 ;;this is fine because the only time this is shared is when it's a local context, 


16 ;;in which case it's a noop 

17 (msg/term (:mq-context worker)) 

18 (log-message "Shutting down transfer thread") 

19 (disruptor/halt-with-interrupt! (:transfer-queue worker)) 
20 

21 (.interrupt transfer-thread) 

22 (.join transfer-thread) 

23 (log-message "Shut down transfer thread") 

24 (cancel-timer (:heartbeat-timer worker)) 


25 (cancel-timer (:refresh-connections-timer worker)) 

26 (cancel-timer (:refresh-active-timer worker)) 

27 (cancel-timer (:executor-heartbeat-timer worker)) 

28 (cancel-timer (:user-timer worker)) 

29 

30 (close-resources worker) 

31 

32 ;; TODO: here need to invoke the "shutdown" method of WorkerHook 

33 

34 (.remove-worker-heartbeat! (:storm-cluster-state worker) storm-id assignment-id port) 
35 (log-message "Disconnecting from storm cluster state context") 

36 (.disconnect (:storm-cluster-state worker)) 

37 (.close (:cluster-state worker)) 

38 (log-message "Shut down worker " storm-id " " assignment-id " " port) 


O 第 2~4 行 关闭 缓存 的 ZMQ 的 Socket 连 接 。 

口 第 8 行 关闭 消息 接收 线程 。 

口 第 12 行 关闭 Worker 中 的 所 有 Executor 线 程 。 

a 第 17 行 关闭 ZMQ 的 上 下 文 ， 释 放 已 经 创建 的 Socket 连 接 。 
口 第 19~22 行 关闭 消息 发 送 队 列 和 线程 。 

O 第 24~28 行 关闭 所 有 的 计时 器 线程 。 

口 第 30 行 关闭 资源 ， 目 前 尚未 使 用 。 

口 第 34 行 从 ZooKeeper 中 清除 该 Worker 的 心跳 信息 。 

口 第 36~37 行 用 于 断 开 与 ZooKeeper 的 连接 。 


9.5 重要 辅助 方法 介绍 


在 创建 Worker 中 的 数据 结构 、 启 动 Worker 以 及 关闭 Worker 的 过 程 中 会 用 到 很 多 辅助 方法 , FH 
解 这 些 方法 有 助 于 我 们 更 好 地 理解 Worker 的 工作 原理 ， 下 面 简 要 介绍 这 些 方法 。 
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9.5.1 Worker 中 的 接收 函数 


Worker 中 的 mk-transfer-local-fn 国 数 用 于 产生 并 发 送 消 息 到 Executor 的 接收 队列 ， 同 一 
Worker 内 部 的 Executor 之 间 会 通过 该 函数 传递 消息 ， 其 代码 如 下 : 


1 (defn mk-transfer-local-fn [worker] 

2 (let [short-executor-receive-queue-map (:short-executor-receive-queue-map worker) 
3 task-»short-executor (:task-»short-executor worker) 

4 task-getter (comp #(get task-»short-executor %) fast-first)] 

5 (fn [tuple-batch] 

6 (let [grouped (fast-group-by task-getter tuple-batch)] 

7 (fast-map-iter [[short-executor pairs] grouped] 

8 (let [q (short-executor-receive-queue-map short-executor)] 


9 (if q 

10 (disruptor/publish q pairs) 

11 (1og-warn "Received invalid messages for unknown tasks. Dropping... ") 
12 ))))))) 


口 第 2 行 的 short-executor-receive-queue-map 存 储 Executor 中 第 一 个 Task 的 TaskId 到 该 

Executor 对 应 的 接收 队列 (Disruptor Queue ) 的 映射 关系 。 

口 第 3 行 的 task->short-executor 用 于 存储 从 该 Worker 中 的 TaskId 到 Executor 中 第 一 个 Task 的 

TaskId 的 映射 关系 。 

O 第 4 行 的 task-getter 函 数 以 ZMQ 发 来 的 消息 为 传人 参数 。 这 里 的 消息 为 一 个 含有 两 个 元 
素 的 数组 ， 第 一 个 元 素 为 TaskId。task-getter 函 数 的 目标 是 通过 消息 的 TaskId 获 得 与 其 对 
应 的 Executor 中 第 一 个 Task 的 TaskId。 第 二 个 元 素 为 消息 的 实际 内 容 。 

a 第 5~12 行 定义 函数 体 ， 函 数 的 输入 为 ZMQ 收 到 的 一 组 消息 tuple-batch。 第 6 行 按照 与 消 

息 TaskId 对 应 的 Executor 中 第 一 个 Task 的 TaskId 对 消息 进行 分 组 ， 其 变量 grouped 对 应 的 键 
为 Executor 中 第 一 个 Task 的 TaskId， 值 为 属于 该 Executor 的 一 组 消息 。 第 8 行 通过 Executor 
中 第 一 个 Task 的 TaskId 获 得 与 Executor 相 对 应 的 接收 消息 队列 q。 第 10 行 调用 
disruptor/publish 方 法 将 收 到 的 消息 发 送 至 队列 中。 车 没有 对 应 的 接收 队列 ， 则 将 消息 
丢 充 ， 这 种 情况 是 不 应 该 发 生 的 。 

下 面 简单 看 一 下 fast-group-by 的 实现 : 


1 (defn fast-group-by [afn alist] 

2 (let [ret (HashMap.)] 

3 (fast-list-iter [e alist] 

4 (let [key (afn e) 

5 “List curr (get-with-default ret key (ArrayList.))] 
6 (.add curr e))) 

7 ret )) 


ra ABR AT Kafie] alist. EHARA, afnytask-getter Px 
数 ，alist 对 应 于 接收 到 的 消息 。 第 2 行 定 义 哈 希 表 类 型 的 ret， 用 于 存储 分 组 的 结果 ; 第 4 行 调用 
afn 函 数 获得 键 ， 当 前 情况 为 获得 TaskId; 第 6 行将 键 对 应 的 值 初 始 化 为 一 个 列表 。 
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9.5.2 ”Worker 中 的 发 送 函 数 


Worker 中 的 mk-transfer-fn 函 数 与 上 一 节 中 介绍 的 mk-transfer-local-fn 类 似 , 它 产生 的 函数 
主要 用 于 Executor 的 数据 发 送 。 这 里 存在 两 种 情况 ， 具 体 如 下 所 示 。 
口 消息 的 目标 TaskId 跟 发 送 TaskId 属 于 同一 个 Worker， 此 时 不 需要 跨 进 程 传输 消息 ， 因 此 可 
将 消息 直接 发 送 至 接收 端 Executor 的 接收 队列 。 
口 消息 的 目标 TaskId 跟 发 送 TaskId 属 于 不 同 的 Worker， 此 时 则 将 消息 发 送 至 Worker 的 发 送 队 
列 ， 由 Worker 负 责 将 队列 中 的 消息 通过 ZMQ 发 送出 去 。 
下 面 来 看 一 下 mk-tzransfer-fn 函 数 的 实现 : 


1 (defn mk-transfer-fn [worker] 

2 (let [local-tasks (-» worker :task-ids set) 

3 local-transfer (:transfer-local-fn worker) 

4 ^DisruptorQueue transfer-queue (:transfer-queue worker)] 
5 (fn [^KryoTupleSerializer serializer tuple-batch] 

6 (let [local (ArrayList.) 

7 remote (ArrayList. )] 

8 (fast-list-iter [[task tuple :as pair] tuple-batch] 


9 (if (local-tasks task) 

10 (.add local pair) 

11 (.add remote pair) 

12 

13 (local-transfer local) 

14 33 not using map because the lazy seq shows up in perf profiles 

15 (let [serialized-pairs (fast-list-for [[task ^TupleImpl tuple] remote] 
[task (.serialize serializer tuple)])] 

16 (disruptor/publish transfer-queue serialized-pairs) 

17 ))))) 


a 第 2 行 的 local-tasks 为 该 Worker 含 有 的 TaskId 集 合 。 
口 第 3 行 的 local-transfer 被 设置 为 Worker 中 的 :transfer-local-fn 变 量 , 该 变量 存储 的 是 一 
个 匿名 函数 ， 这 个 匿名 函数 通过 调用 9.$.1 节 中 介绍 的 mk-transfer-local-fn 国 数 得 到 。 
O 第 4 行 的 transfer-queue 为 与 Worker 对 应 的 消息 发 送 队 列 。 
a 第 5$ 行 定义 了 一 个 函数 ， 其 参数 为 一 个 序列 化 器 serializer 和 一 组 消息 。 
a 第 6~12 行 将 消息 分 组 ，local 用 于 存储 发 送 到 同一 个 Worker 中 其 他 Task 的 消息 ，remote 用 
于 存储 发 送 到 其 他 Worker 的 Task 的 消息 。 
O 第 13 行 调用 local-transfer 方 法 处 理 local 列 表 中 的 消息 。 
a 第 15 行 调用 序列 化 器 对 消息 进行 序列 化 处 理 然后 将 其 发 送 到 transfer-queue 中 , 注意 这 里 
只 需要 对 消息 进行 序列 化 。 
那么 , Worker 是 如 何 接收 数据 的 呢 ? Worker 中 会 有 一 个 额外 的 线程 对 transfer-queue 进 行 监听 ， 
函数 mk-transfer-tuples-hanlder 用 于 创建 与 Disruptor Queue 对 应 的 消息 处 理 器 ， 相 关 代码 如 下 : 


1 (defn mk-transfer-tuples-handler [worker] 
2 (let [^DisruptorQueue transfer-queue (:transfer-queue worker) 
3 drainer (ArrayList.) 


E% ae 
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4 noderport-»socket (:cached-node+port->socket worker) 
5 task->nodetport (:cached-task->nodetport worker) 
6 endpoint-socket-lock (:endpoint-socket-lock worker) 
7 ] 
8 (disruptor/clojure-handler 
9 (fn [packets _ batch-end?] 
10 (.addAll drainer packets) 
11 (when batch-end? 
12 (read-locked endpoint-socket-lock 
13 (let [node+port->socket @node+port->socket 
14 task->nodetport @task->node+tport] 
15 33 consider doing some automatic batching here (would need to 
not be serialized at this point to remove per-tuple overhead) 
16 ;; try using multipart messages ... first sort the tuples by the 
target node (without changing the local ordering) 
17 
18 (fast-list-iter [[task ser-tuple] drainer] 
19 33 TODO: consider write a batch of tuples here to every 
target worker 
20 33 group by nodetport, do multipart send 
21 (let [node-port (get task->nodetport task) ] 
22 (when node-port 
23 (msg/send (get nodetport->socket node-port) task ser-tuple)) 
24 )) 
25 (.clear drainer)))))) 


a 第 3 行 的 drainer 列 表 用 于 缓存 要 发 送 的 消息 。 Disruptor Queue 的 Onevent 回 调 会 调用 本 函数 
定义 的 方法 ， 该 方法 的 最 后 一 个 参数 表示 Queue 是 否 为 一 个 Batch 结 束 ， 并 会 在 Batch 结 


之 前 将 消息 缓存 到 drainer 列 表 中 。 


a 第 4 行 的 node+port->socket 保 存 了 Worker 中 与 目标 node+port 相 对 应 的 ZMQ Socket 连 接 。 
node+port 代 表 Nimbus 的 资源 分 配 单位 ，node 则 表示 一 台 运 行 Supervisor 的 机 器 ，port 为 该 


Supervisor 上 某 一 个 运行 Worker 的 端口 号 。 


口 第 5 行 的 task->node+port 为 从 TaskId 到 node+port 的 映射 关系 。 


口 第 6 行 的 endpoint-socket-lock 为 Worker 中 定义 的 ReentrantReadWriteLock 类 
Worker 中 存在 一 个 专门 的 线程 ， 会 对 缓存 的 ZMQ 连 接 进 行 更 新 。 

a 第 8 行 定义 了 一 个 clojure-handler, 与 其 对 应 的 函数 在 第 9 行 定义 。 该 函数 的 第 1 个 传 入 参 
数 为 一 组 消息 packets， 第 二 个 参数 被 忽略 ， 第 三 个 参数 表明 该 Batch 是 否 结束 。 

口 第 10 行 将 消息 packets 放 人 drainer 变 量 中 。 若 batch-end? 为 true， 则 为 了 避免 跟 ZMQ 连 接 


型 的 锁 , 


更 新 线程 相 冲 突 , 这 里 需要 申请 读 取 endpoint-socket-1lock 锁 ,然后 遍历 drainer 中 缓存 的 
所 有 消息 ， 根 据 消 息 的 taskId 找 到 node+port ， 然 后 通过 从 node+port 到 ZMQSocket 的 映射 


关系 找到 对 应 的 Socket 连 接 。 
口 第 23 行 调用 msg/send 函 数 将 消息 发 送出 去 。 
O 第 25 行 用 于 清理 drainer 绥 存 。 
在 Worker 中 ， 我 们 使 用 下 面 的 方法 来 启动 发 送 监听 线程 : 
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transfer-tuples (mk-transfer-tuples-handler worker) 
transfer-thread (disruptor/consume-loop* (:transfer-queue worker) transfer-tuples) 


9.5.3 ”获取 属于 Worker 的 Executor 


read-worker-executors 子 数 用 来 计算 分 配 到 该 Worker 的 Executor, 它 通过 调用 storm-cluster- 
state 的 assignment-info 函 数 获得 所 有 Topology 的 分 配 信息 ， 然 后 利用 Worker 的 assignment-id 以 
及 port 进 行 过 滤 ， 得 到 某 个 Worker 所 属 的 Executor， 这 里 assignment-id 对 应 于 node。Worker 启 动 
后 ， 其 执行 的 Executor 集 合 将 不 再 发 生变 化 。 但 当 任务 分 配 情况 发 生变 化 时 ，Supervisor 就 会 重启 
Worker 来 处 理 任务 。 其 中 ，Nimbus 在 计算 任务 分 配 时 会 尽量 不 改变 Worker 中 已 执行 的 Executor。 
当前 Worker 中 任何 一 个 Executor 处 理 失 败 都 会 导致 Worker 重 启 ,也 即 Worker 中 其 他 Executor 的 重新 
启动 ，Storm 可 以 考虑 对 此 进行 优化 。 该 函数 的 代码 如 下 : 


(defn read-worker-executors [storm-conf storm-cluster-state storm-id assignment-id port] 


(let [assignment (:executor->node+port (.assignment-info storm-cluster-state storm-id nil))] 
(doall 


(concat 
[Constants/SYSTEM EXECUTOR ID] 
(mapcat (fn [[executor loc]] 
(if (= loc [assignment-id port]) 
[executor] 


assignment))))) 


9.5.4 创建 Executor 的 接收 消息 队列 和 查找 表 


mk-ireceive-queue-map 函 数 用 于 为 Worker 中 的 每 一 个 Executor 创 建 接收 队列 , 并 将 其 存 人 哈 希 
表 ， 其 中 键 为 ExecutorId， 值 为 Disruptor Queue 的 对 象 ， 其 代码 如 下 : 


(defn- mk-receive-queue-map [storm-conf executors] 
(-»» executors 


33 TODO: this depends on the type of executor 


(map (fn [e] [e (disruptor/disruptor-queue (storm-conf TOPOLOGY-EXECUTOR-RECEIVE- 
BUFFER-SIZE) 


:wait-strategy (storm-conf TOPOLOGY-DISRUPTOR-WAIT-STRATEGY) ) ])) 
(into {}) 
)) 
ExecutorId 实 际 上 为 含有 两 个 元 素 的 数组 ， 即 [startTaskId，endTaskId] ， 表 示 该 Executor 要 
执行 的 任务 区 间 。 


在 Worker 中 ， 我 们 定义 了 几 个 哈 希 表 以 方便 对 信息 进行 查找 。 下 面 来 看 一 下 它们 的 关系 : 


1 executor-receive-queue-map (mk-receive-queue-map storm-conf executors) 

2 receive-queue-map (-»» executor-receive-queue-map 

3 (mapcat (fn [[e queue]] (for [t (executor-id-»tasks e)] [t queue]))) 
4 (into {})) 
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:task-ids (-»» receive-queue-map keys (map int) sort) 
:short-executor-receive-queue-map (map-key first executor-receive-queue-map) 
:task-»short-executor (-»» executors 

9 (mapcat (fn [e] (for [t (executor-id-»tasks e)] [t (first e)]))) 

10 (into {}) 

11 (HashMap.)) 

12 :executor-receive-queue-map executor-receive-queue-map 


oo ~ O^ un 


a 第 1 行 调 用 mk-receive-queue-map 创 建 Disruptor Queue， 并 在 第 12 行 将 其 赋值 给 :executor- 
receive-queue-map. 
O 第 2~4 行 调用 executor-id->tasks 函 数 获 得 Executor 中 包含 的 TaskId 集 合 ， 并 创建 哈 希 表 ， 
键 为 Taskld， 值 为 该 Task 所 属 的 Executor 的 接收 队列 。 
口 第 6 行 获得 Executor 中 包含 的 TaskId 集 合 ， 即 为 receive-queue-map 的 键 集合 。 
口 第 7 行 构 建 一 个 新 的 哈 希 表 , 存储 从 Executor 的 开始 TaskId 到 该 Executor 的 接收 队列 的 映射 关系 。 
a 第 8~11 行 构建 Executor 中 从 TaskId 到 Executor 的 起 始 TaskId 的 映射 关系 。 

于 是 , 对 于 接收 到 的 一 组 消息 , 根据 其 TaskId 找 到 Executor 的 起 始 TaskId 并 根据 其 进行 消息 分 
组 ， 然 后 根据 从 起 始 TaskId 到 Executor 接 收 队 列 的 哈 希 表 short-executor-Teceive-queue-map 来 进 
行 消息 的 分 发 。 

在 Worker 中 ，TaskId、Executor 以 及 Executor 的 收发 队列 的 哈 希 表 的 关系 如 下 所 示 。 
口 :executor-receive-queue-map: [startTaskId，endTaskId]->Executor 接 收 队列 ; 
O :short-executor-receive-queue-map: [startTaskId]->Executor 接 收 队列 ; 
Q receive-queue-map: [taskId]->Executor 接 收 队 列 ; 
口 :task->short-executor: [taskId]->[startTaskId]. 


9.5.5 ”下载 Topology 的 配置 项 以 及 代码 


在 执行 一 个 Topology 时 ，Supervisor 将 从 Nimbus 下 载 3 个 文件 ， 它 们 分 别 为 stormconf.ser、 
stormcode.ser 和 stormjar.jar。 其 中 ,stormconf.ser 为 Topology 配 置 项 的 序列 化 文件 ,read-supervisor- 
storm-conf 函 数 用 于 读 取 该 文件 并 将 其 反 序 列 化 。stormcode.ser 为 Topology 的 定义 文件 ， 可 通过 
read-supervisor-topology PK ZI c ie BU CIF, 并 将 其 反 序 列 化 解析 。 read-supervisor-storm- 
conf #llread-supervisor-topology PACH RSUN F : 


(defn read-supervisor-storm-conf [conf storm-id] 
(let [stormroot (supervisor-stormdist-root conf storm-id) 
conf-path (supervisor-stormconf-path stormroot) 
topology-path (supervisor-stormcode-path stormroot)] 
(merge conf (Utils/deserialize (FileUtils/readFileToByteArray (File. conf-path)))) 


)) 


(defn read-supervisor-topology [conf storm-id] 
(let [stormroot (supervisor-stormdist-root conf storm-id) 
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topology-path (supervisor-stormcode-path stormroot)] 
(Utils/deserialize (FileUtils/readFileToByteArray (File. topology-path))) 


)) 
从 Nimbus 下 载 的 这 些 文件 在 Supervisor 所 在 机 器 的 路 径 如 下 : 
$StormRoot/stormData/supervisor/stormdist/«stormid»/ 


stormjar.jar 文 件 包 含 了 用 户 的 资源 文件 ， 如 第 三 方 库 等 。Storm 会 将 该 jar 文 件 进行 解压 ， 并 放 
置 于 运行 目录 的 resources 文 件 夹 下 面 ， 具 体 为 : 


$StormRoot/stormData/supervisor/stormdist/<stormid>/resources 
9.6 ”小结 
Worker 中 的 线程 及 其 通信 关系 如 图 9-2 所 示 ， 读 者 可 以 结合 代码 进行 分 析 。 
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图 9-2 Worker 中 的 线程 以 及 通信 关系 


Executor 


Executor 是 Storm 的 核心 运行 单位 ， 一 个 Executor 实 际 上 就 是 一 个 线程 。 一 个 Worker 中 可 以 启 


动 一 个 或 多 个 Executor， 而 一 个 Executor 又 可 以 含有 多 个 Task, 这 些 Task 为 逻辑 运行 单位 属于 相同 
的 组 件 。 一 个 组 件 中 含有 的 Executor 数 目 与 其 并 行 度 设置 (parallelism hint) 有 关 ， 该 参数 表 
示 组 件 希 望 以 多 少 个 线程 来 执行 。 每 个 组 件 还 可 以 调用 setNumTasks 方 法 来 设置 其 含有 的 Task 数 
目 为 。Storm 会 根据 一 个 组 件 的 Task 数 目 及 并 行 度 设置 来 计算 哪些 Task 应 该 被 分 配 到 哪些 
Executor 中 ， 请 参照 第 7 章 的 内 容 来 理解 。Executor 实 际 上 包含 了 [startTaskId，endTaskId] 区 间 
内 所 有 的 Task。 若 未 设置 Task 数 目 ， 则 默认 情况 下 Task 数 目 与 Executor 数 目 相 同 ， 每 个 Executor 


中 只 含有 个 Task。 


10.1 Executor 的 数据 


mk-executor-data 国 数 用 于 定义 Executor 中 含有 的 数据 ， 理 解 Executor 中 的 数据 对 于 理解 
Executor 是 至 关 重 要 的 。 表 10-1 详 细 介 绍 了 这 些 数据 。 


表 10-1 Executor 中 的 数据 及 其 描述 


数据 名 称 


获取 方法 


:worker 


:worker-context 


:executor-id 


:task-ids 


:component-id 


:open-or-prepare 
-was-called? 


参数 传人 
调用 worker-context 函数 
获得 


参数 传人 


调用 方法 


executor-id->tasks 获 得 


.getComponentId 
worker-context (first 
task-ids) 


(atom false) 


Executor 所 在 的 Worker 引 


uu 


WorkerTopologyContextX] 4 


Executor 的 标识 符 ， 为 含有 两 个 元 素 的 数组 [start-task-id， 
last-task-id] ， 它 标识 了 Executor 的 任务 区 间 


zi 


TRIS ExecutorBiJexecutor-idlR4EHJTaskrdBgz FAIRER , uk 
与 该 Executor 对 应 的 TaskId 


与 Executor 对 应 的 ComponentId， 


通过 调用 workerTopologyContext 对 象 的 getComponentId 方 法 获得 


表征 Spout 的 open 方 法 或 者 Bolt 的 prepare 方 法 是 否 被 调用 ,与 运行 
统计 相关 
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数据 名 称 


获取 方法 


(5E) 
描 x 


:storm-conf 


:receive-queue 


:storm-id 
:conf 
:shared-executor-data 


:storm-active-atom 


:batch-transfer-queue 


:transfer-fn 


:suicide-fn 


:storm-cluster-state 


:stats 


:type 


:interval->task->metric 
-registry 


:task->component 


:stream->component->gro 
uper 


:report-error 


:report-error-and-die 


:deserializer 


:sampler 


normalized-component-co 
nf (:storm-conf worker) 
worker-context 
component-id 


(:executor-receive-queue- 
map worker) executor-id 


(:storm-id worker) 
(:conf worker) 
(HashMap. ) 


(:storm-active-atom 
worker) 


disruptor/disruptor-queue 


(mk-executor-transfer-fn 
batch-transfer-»worker) 


(:suicide-fn worker) 


cluster/mk-storm-cluste 
r-state (:cluster-state 
worker) 


mk-executor-stats «» 
(sampling-rate 
storm-conf) 
executor-type worker- 
context component-id 


(HashMap. ) 


(:task-»component 
worker) 


outbound-components 
worker-context 
component-id 


throttled-report-error- 
fn <> 


fn [error] 
((:report-error) error) 
((:suicide-fn)) 
KryoTupleDeserializer. 
storm-conf 
worker-context 


mk-stats-sampler storm- 
conf 


委 组 件 自 定 义 的 配置 项 与 Topology 的 配置 项 合并 , 每 个 组 件 可 以 
自 定义 如 下 配置 项 : 

TOPOLOGY-DEBUG 

TOPOLOGY -MAX- SPOUT - PENDING 

TOPOLOGY -MAX- TASK - PARALLELISM 

TOPOLOGY- TRANSACTIONAL- ID 

TOPOLOGY-TICK-TUPLE-FREO-SECS 

TOPOLOGY -SLEEP-SPOUT-WAIT-STRATEGY-TIME-MS 
TOPOLOGY - SPOUT -WAIT-STRATEGY 
normalized-component-confPK Zi FH FH Ace FF 


从 Worker 中 获得 该 Executor 的 接收 队列 


Oooooodo 


从 Worker 中 获得 StormId 标 识 符 

获取 Worker 的 配置 

表示 一 个 Executor 中 所 有 Task 的 共享 数据 
表征 该 Topology 是 否 为 活路 状态， 从 Worker 获 取 


Executor 的 消息 发 送 队 列 ， 为 Disruptor Queue 类 型 


Executor 的 消息 发 送 函 数 ， 通 过 mk-executor-transfer-fn 函 数 获 
得 ， 消 息 被 发 送 到 :batch-transfer-queue 队 列 中 


异常 处 理 函 数 ， 用 于 退出 进程 ， 从 Worker 获 得 


Storm 的 运行 状态 , 主要 与 ZooKeeper 进 行 交 互 , 其 他 章节 有 讨论 


Executor 的 运行 统计 信息 ，Spout 与 Bolt 对 应 于 不 同 的 统计 信息 。 
它 通 过 调用 mk-executor-stats 定 义 


Executor 的 类 型 ， 为 Spout 或 者 Bolt 


系统 的 内 置 运 行 统计 信息 ,含义 为 每 个 统计 间隔 上 每 个 Task 的 统 10 


计 信息 
从 Task 到 组 件 的 对 应 关系 ， 


Worker 获 得 


从 流 到 接收 组 件 及 分 组 函数 的 哈 希 表 


报告 错误 方法 ， 后 面 会 


步 讨论 


报告 错误 并 且 退 出 


消息 的 反 序 列 化 器 


运行 统计 采样 器 
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10.2 Executor 的 输入 和 输出 


每 一 个 Executor 对 应 两 个 Disruptor Queue， 分 别 用 于 输入 与 输出 。 


10.2.1 Executor 的 输入 及 处 理 


Worker 在 初始 化 时 ， 会 为 其 所 包含 的 每 一 个 Executor 创 建 一 个 Disruptor Queue， 用 于 接收 数 
据 。 在 创建 Executor 时 ， 可 根据 其 executor-id 从 Worker 的 :executor-receive-queue-map 中 获得 该 
队列 的 引用 : 


:receive-queue ((:executor-receive-queue-map worker) executor-id) 


当 Worker 的 接收 线程 从 ZMQ 收 到 数据 后 ， 线 程 会 根据 目标 的 TaskId 找 到 对 应 的 Executor， 并 
将 数据 发 送 到 该 Executor 所 对 应 的 接收 Disruptor Queue 中 。 对 于 输入 Disruptor Queue 中 的 消息 ,Bolt 
类 型 的 Executor 会 调用 Bolt 对 象 的 Execute 方 法 来 人 处理, 而 Spout 类 型 的 Executor 则 调用 Spout 对 象 的 
Ack 或 Fail 方 法 处 理 。 

mk-task-receiver 图 数 定义 了 一 个 函数 来 处 理 Disruptor Queue 中 的 消息 ， 它 通过 调用 
disruptor/clojure-handler 消 数 获取 一 个 消息 处 理 函 数 ， 该 消息 处 理 函 数 会 在 收 到 新 消息 时 被 调用 。 
clojure-handler 哨 数 要 求 传人 一 个 隐 数 。mk-task-receiver 函 数 的 代码 如 下 : 


1 (defn mk-task-receiver [executor-data tuple-action-fn] 

2 (let [^KryoTupleDeserializer deserializer (:deserializer executor-data) 

3 task-ids (:task-ids executor-data) 

4 debug? (= true (-> executor-data :storm-conf (get TOPOLOGY-DEBUG))) 

5 ] 

6 (disruptor/clojure-handler 

7 (fn [tuple-batch sequence-id end-of-batch?] 

8 (fast-list-iter [[task-id msg] tuple-batch] 

9 (let [^TupleImpl tuple (if (instance? Tuple msg) msg (.deserialize 
deserializermsg))] 


10 (when debug? (log-message "Processing received message " tuple)) 
11 (if task-id 

12 (tuple-action-fn task-id tuple) 

13 ;; null task ids are broadcast tuples 

14 (fast-list-iter [task-id task-ids] 

15 (tuple-action-fn task-id tuple) 

16 

17 20)» 


a 第 1 行 中 形 参 tuple-action-fn 是 Executor 处 理 消 息 的 函数 ， 而 且 Spout 线 程 与 Bolt 线 程 处 理 
消息 的 函数 是 不 同 的 ， 这 在 后 面 会 详细 介绍 。 

a 收 到 消息 后 ,将 调用 Disruptor 的 onEvent 函 数 ， 第 7~16 行 定义 该 函数 。 在 第 9 行 中 , 若 消 息 
已 经 为 Tuple 对 象 ， 则 不 需要 再 进行 反 序列 化 。 例 如 ， 该 消息 是 由 属于 同一 个 Worker 的 其 
他 Task 发 送 过 来 的 。 
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Q 281147, 若 存 在 消息 的 来 源 task-id, 则 调用 一 次 tuple-action-fn 函 数 ; A ATHE task-id, 
则 在 该 Executor 中 的 所 有 Task 上 调用 tuple-action-fn 函 数 。 
在 创建 Spout 或 Bolt 时 ， 会 调用 mk-task-receiver 函 数 并 将 结果 存储 于 event-handler 变 量 中 ; 


event-handler (mk-task-receiver executor-data tuple-action-fn) 

在 Spout 中 以 非 阻塞 方式 接收 数据 : 

(disruptor/consume-batch receive-queue event-handler) 

而 在 Bolt 中 ， 则 以 阻塞 方式 接收 数据 : 
(disruptor/consume-batch-when-available receive-queue event-handler) 


Bolt 的 消息 循环 主要 调用 event-handler 中 的 方法 来 对 消息 进行 处 理 。 其 实 Bolt 的 数据 接收 并 
不 是 严格 意义 上 阻塞 的 ， 即 知 等 竺 一定 时间 后 仍然 没有 输入 ， 函 数 将 返回 空 集 合 。 


10.2.2 ”Executor 的 输出 及 发 送 


每 个 Executor 都 会 产生 一 个 用 于 输出 的 Disruptor Queue 对 象 ，Executor 在 发 送 消息 时 首先 会 将 
消息 内 容 发 送 到 该 队列 中 。Executor 会 启动 一 个 发 送 线程 来 处 理 该 队列 中 的 数据 ， 该 线程 调用 
Worker 中 由 mk-transfer-fn 产 生 的 函数 对 数据 进行 处 理 ， 或 者 把 数据 通过 ZMQ 发 送 到 其 他 
Worker， 或 者 直接 发 送 到 与 该 Worker 上 的 其 他 Executor 相 对 应 的 接收 Disruptor Queue 中 。 

start-batch-transfer-»worker-handler! K% disruptor/consume-loop* ŽEJA 5H 
于 发 送 数据 队列 的 发 送 线程 ， 相 关 代 码 如 下 : 


1 (defn start-batch-transfer-»worker-handler! [worker executor-data] 
2 (let [worker-transfer-fn (:transfer-fn worker) 

3 cached-emit (MutableObject. (ArrayList.)) 

4 storm-conf (:storm-conf executor-data) 

5 serializer (KryoTupleSerializer. storm-conf (:worker-context executor-data)) 
6 ] 

7 (disruptor/consume-loop* 

8 (:batch-transfer-queue executor-data) 

9 (disruptor/handler [o seq-id batch-end?] 

10 (let [*ArrayList alist (.getObject cached-emit) ] 
11 (.add alist o) 

12 (when batch-end? 

13 (worker-transfer-fn serializer alist) 

14 (.setObject cached-emit (ArrayList.)) 

15 

16 :kill-fn (:report-error-and-die executor-data)))) 


O 第 2 行 的 worker-transfer-fn 为 Worker 中 由 mk-transfer-fn 定 义 的 函数 ， 用 于 发 送 Disruptor 
Queue 中 的 一 个 数据 。 
a 第 3 行 的 cached-emit 为 列表 类 型 的 对 象 数组 ， 用 于 缓存 要 发 送 的 数据 。Disruptor Queue 是 
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批量 处 理 数据 的 ， 它 在 真正 处 理 这 批 数 据 之 前 ， 数 据 会 被 放 人 cached-emit 列 表 中 。 
a 第 5 行 生成 一 个 KryoTupleSerializer， 用 来 对 发 送 的 数据 进行 序列 化 。 


a 第 7~15 行 启动 Disruptor Queue 的 消费 者 线程 。 第 8 行 的 : batch-transfer-queue 为 Executor 


定义 的 Disruptor Queue 对 象 。 在 第 12~15 行 中 ，batch-end? 参 数 用 于 表明 Disruptor Queue 是 
否 准备 对 消息 进行 处 理 。 若 处 理 ， 则 调用 worker-transfer-fn 发 送 缓存 的 消息 ， 同 时 将 


cached-emit 对 象 重 置 为 一 个 空 列表 。 


O 第 16 行 传人 Executor 的 report-error-and-die 函 数 , 该 函数 将 对 错误 进行 记录 并 退出 进程 。 


在 创建 Executor 的 过 程 中 ， 我 们 会 启动 线程 system-threads ( mk-executorPAZK ): 


system-threads [(start-batch-transfer-»worker-handler! worker executor-data)] 


Executor 在 创建 其 数据 时 会 创建 该 发 送 队 列 ， 下 面 的 代码 用 于 创建 发 送 队 列 : 


batch-transfer-»worker (disruptor/disruptor-queue 
(storm-conf TOPOLOGY-EXECUTOR-SEND- BUFFER-SIZE) 
:claim-strategy :single-threaded 
:wait-strategy (storm-conf TOPOLOGY-DISRUPTOR-WAIT-STRATEGY) 


10.3 Spout 类 型 的 Executor 


mk-threads 函 数 用 于 创建 与 Executor 对 应 的 消息 循环 主线 程 。Spout 和 Bolt 有 着 不 同 的 消 
环 策略 ， 故 需 分 别 进 行 定义 。 下 面 的 代码 用 于 定义 接口 ，Spout 和 Bolt 会 分 别 实现 该 接口 : 


(defmulti mk-threads executor-selector) 


E 


mk-threads 函 数 的 主 消息 循环 通过 async-loop 方 法 实现 ， 若 传人 的 函数 为 工厂 方 法， 则 在 第 
一 次 调用 该 方法 时 进行 初始 化 ,并 返回 用 于 消息 循环 的 函数 。 为 了 便于 讨论 以 及 节约 篇 幅 ， 本 节 


将 前 面 讨论 过 的 方法 实现 略 去 。 
10.3.1 准备 消息 循环 的 数据 
这 部 分 数据 在 mk-threads 的 let 方 法 中 定义 : 


1 (let [{:keys [storm-conf component-id worker-context transfer-fn report-error sampler 
open-or-prepare-was-called?]} executor-data 
^ISpoutWaitStrategy spout-wait-strategy (init-spout-wait-strategy storm-conf) 
max-spout-pending (executor-max-spout-pending storm-conf (count task-datas)) 
^Integer max-spout-pending (if max-spout-pending (int max-spout-pending)) 
last-active (atom false) 
spouts (ArrayList. (map :object (vals task-datas))) 
rand (Random. (Utils/secureRandomLong)) 


pending (RotatingMap.2 
33 microoptimize for performance of .size method 


PO ON AU BPWN 


o 
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11 (reify RotatingMap$ExpiredCallback 

12 (expire [this msg-id [task-id spout-id tuple-info start-time-ms]] 

13 (let [time-delta (if start-time-ms (time-delta-ms start-time-ms))] 

14 (fail-spout-msg executor-data (get task-datas task-id) 
spout-id tuple-info time-delta) 

15 )))) 

16 tuple-action-fn (后 面 会 单独 介绍 ) 

17 receive-queue (:receive-queue executor-data) 

18 event-handler (mk-task-receiver executor-data tuple-action-fn) 

19 has-ackers? (has-ackers? storm-conf) 

20 emitted-count (MutableLong. 0) 

21 empty-emit-streak (MutableLong. 0) 

22 overflow-buffer (LinkedList.) ] 


O 第 1 行 表明 了 mk-threads 函 数 将 使 用 的 Executor 数 据 。 

O 第 2 行 定 义 Spout 的 等 待 策略 spout-wait-strategy ， 该 策略 通过 调用 init-spout-wait- 
strategy 函 数 来 得 到 ,由 配置 项 TOPOLOGY-SPOUT-WAIT-STRATEGY 进 行 配 置 , 该 策略 用 于 Spout 
的 nextTuple 函 数 多 次 没有 消息 输出 的 情况 ， 此 时 系统 将 默认 使 用 SleepSpoutwait 
Strategy， 即 该 情况 下 Spout 将 睡眠 一 段 时 间 。 

O 第 3 行 获得 消息 的 max-spout-pending 数 目 ， 通 过 计算 配置 项 TOPOLOGY-MAX-SPOUT-PENDING 
与 当前 Executor 中 Task 数 目的 乘积 来 获得 。 当 该 Executor 中 存在 超过 max-spout-pending 数 
目的 消息 没有 被 Ack 或 Fail 时 ，Spout 将 进入 等 待 状态 ， 并 利用 该 参数 进行 流量 控制 。 

口 第 5 行 的 last-active 表 明 Spout 的 状态 。 当 Topology 处 于 非 活 路 状态 时 ，1last-active 将 被 

设置 为 false， 此 时 Spout 不 会 向 外 发 送 数据 。 

O 第 6 行 获得 该 Executor 包 含 的 Spout 对 和 象 集合 。 每 一 个 Task 对 应 着 一 个 Spout 对 象 , 依次 调用 

Spout 的 nextTuple 方 法 来 发 送 消息 。 

O 第 9~15 行 定义 pending 变 量 , 用 于 存储 已 发 送出 去 但 未 被 Ack 或 Fail 的 消息 。 在 RotatingMap 
对 象 中 , 我 们 可 以 设置 回调 函数 。 当 系统 收 到 SYSTEM_TICK 的 时 候 , 将 调用 pending 的 rotate 
方法 。 于 是 第 11~15 行 定义 的 ExpiredCallback 方 法 会 被 调用 ， 以 对 每 一 条 消息 调用 
fail-spout-msg 函 数 进行 处 理 ， 即 调用 Spout 的 Fail 回 调 。 

a 第 16 行 的 tuple-action-fn 消 数 用 于 处 理 Spout 收 到 的 消息 。 

口 第 17 行 的 receive-queue 对 应 于 Executor 的 接收 队列 。 

O 第 18 行 的 event-handler 用 来 处 理 Spout 收 到 的 消息 ， 它 将 调用 tuple-action-fn 函 数 。 

O 第 19 行 定义 has-ackers? 来 表明 系统 中 是 否 存 在 Acker Bolt. 

口 第 22 行 定义 了 overflow-buffer ,在 Executor 所 对 应 的 Disruptor Queue 发 送 队 列 已 被 填 满 时 ， 
消息 将 被 发 送 到 overflow-buffer 中 。Spout 发 送 消 息 时 ,优先 发 送 overflow-buffer 中 的 数 
据 。 另 外 ，Spout 的 主 循环 要 求 每 一 步 操作 都 是 非 阻塞 的 。 

口 第 20 行 定义 的 emitted-count 用 来 记录 Executor 发 送 的 消息 数目 ， 而 第 21 行 empty- 

emit-streak 变 量 则 用 来 记录 连续 调用 nextTuple 函 数 且 无 消息 发 送 的 数目 ， 它 会 被 当 作 

spout-wait-strategy 的 emitEmpty 方 法 的 参数 。 


TIT 
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10.3.2 ”Spout 输入 处 理 函 数 


对 于 Spout 类 型 的 Executor 来 讲 ， 


Ack/Fail 消 息 、 系 统 的 tick 消 息 等 。Spout 主 线程 消 


输入 消息 主要 是 系统 消息 ， 例 如 对 发 出 消息 进行 回复 的 


Spout 会 采用 非 阻塞 的 方式 从 接收 队列 中 获取 消息 。 
Spout 在 收 到 消息 后 调用 的 消息 处 理 函 数 如 下 : 


1 tuple-action-fn (fn [task-id ^TupleImpl tuple] 
2 (let [stream-id (.getSourceStreamId tuple)] 


(condp = stream-id 


3 
4 Constants/SYSTEM TICK STREAM ID (.rotate pending) 
5 Constants/METRICS TICK STREAM ID (metrics-tick executor-data 


task-datas tuple) 


息 循 环 需 要 做 很 多 工作 ， 为 了 不 影响 其 他 工作 ， 


6 (let [id (.getValue tuple 0) 
7 [stored-task-id spout-id tuple-finished-info start-time-ms] 
(.remove pending id)] 
8 (when spout-id 
9 (when-not (= stored-task-id task-id) 
10 (throw-runtime "Fatal error, mismatched task ids: "task-id " " 
stored-task-id)) 
11 (let [time-delta (if start-time-ms (time-delta-msstart-time-ms))] 
12 (condp = stream-id 
13 ACKER-ACK-STREAM-ID (ack-spout-msg executor-data (get 
task-datas task-id) 
14 spout-id tuple-finished-info time-delta) 
15 ACKER-FAIL-STREAM-ID (fail-spout-msg executor-data 
(get task-datas task-id) 
16 pout-id tuple-finished-info time-delta) 
17 )) 
18 33 TODO: on failure, emit tuple to failure stream 
19 ))) 


第 2 行 计 算 收 到 消息 的 来 源 。 若 消息 来 自 SYSTEM_TICK_STREAM-ID , 则 调用 pending 对 象 的 rotate 
方法 ， 该 方法 将 导致 发 送 消 息 超时 。 在 进行 消息 跟踪 的 过 程 中 ，Spout 会 用 pending 对 象 来 保存 所 


有 发 送出 去 的 消息 ， 用 SYSTEM_TICK 消 


丢失 ， 导 致 Spout 中 的 该 消息 没有 被 Ack， 则 Spout 会 在 收 到 Tick 消 
作 来 清理 缓存 ， 然 后 调用 该 消息 的 Fail 操 作 并 交 由 用 户 来 决定 是 进行 重 传 还 是 将 其 忽略 。 若 消息 
来 自 METRICS_TICK_STREAM_ID, 则 调用 metrics-tick 方 法 来 整理 


统计 Bolt 节 点 上 去 。 


息 作 为 清理 缓存 消息 的 信号 。 例 如， 若 某 个 消息 的 Ack 消 息 
息 后 调用 pending 对 象 的 超时 操 


is 


目前 的 统计 信息 并 将 其 发 送 到 信息 


其 他 的 消息 来 源 只 能 为 Ack/Fail 的 流 。 于 是 ， 第 6 行 获得 消息 的 第 1 列 ， 即 发 送 的 消息 ID， 它 
是 一 个 在 发 送 时 随机 产生 的 long 类 型 的 对 象 . 第 7 行将 该 ID 对 应 的 数据 从 pending 数 组 中 清除 出 去 ， 


该 ID 对 应 的 数据 被 返回 ， 其 内 容 为 : 


[stored-task-id, spout-id, tuple-finished-info, start-time-ms] 


其 中 stored-task-id 为 发 送 该 消 


息 的 TaskId ，spout-id 为 发 送 消 


息 时 附带 的 Messageld , 
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tuple-finished-info 含 有 发 送 消息 的 StreamId 以 及 消息 内 容 ，start-time-ms 则 在 消息 被 执行 统计 
采样 时 ， 存 储 为 当前 时 间 ， 否 则 为 空 ， 如 下 面 的 代码 所 示 : 


(.put pending root-id [task-id 
message-id 
{:stream out-stream-id :values values} 
(if (sampler) (System/currentTimeMillis))]) 


若 消 息 来 自 于 ACKER-ACK-STREAM-ID， 则 调用 ack-spout-msg 回 调 方法 处 理 消 息 ; 若 消 息 来 自 
ACKER-FAIL-STREAM-ID， 则 调用 fail -spout -msg 方 法 进行 处 理 。 


ack-spout-msg 函 数 主 要 调用 用 户 的 spout 对 象 的 Ack 回 调 方法 , 同时 更 新 相关 的 统计 信息 , 其 
代码 如 下 : 


(defn- ack-spout-msg [executor-data task-data msg-id tuple-info time-delta] 
(let [storm-conf (:storm-conf executor-data) 
^ISpout spout (:object task-data) 
task-id (:task-id task-data)] 
(when (= true (storm-conf TOPOLOGY-DEBUG)) 
(log-message "Acking message " msg-id)) 
(.ack spout msg-id) 
(task/apply-hooks (:user-context task-data) .spoutAck (SpoutAckInfo. msg-id task-id 
time-delta)) 
(when time-delta 
(builtin-metrics/spout-acked-tuple! (:builtin-metrics task-data) (:stats 
executor-data) (:stream tuple-info) time-delta) 
(stats/spout-acked-tuple! (:stats executor-data) (:stream tuple-info) 
time-delta)))) 


fail-spout-msg 国 数 主要 调用 Spout 对 象 的 Fail 回 调 方法 ， 其 代码 如 下 : 


(defn- fail-spout-msg [executor-data task-data msg-id tuple-info time-delta] 
(let [^ISpout spout (:object task-data) 

task-id (:task-id task-data)] 

;;T0DO: need to throttle these when there's lots of failures 

(log-debug "Failing message " msg-id ": " tuple-info) 

(.fail spout msg-id) 

(task/apply-hooks (:user-context task-data) .spoutFail (SpoutFailInfo. msg-id task-id 
time-delta)) 

(when time-delta 
(builtin-metrics/spout-failed-tuple! (:builtin-metrics task-data) (:stats executor-data) 

(:stream tuple-info)) 

(stats/spout-failed-tuple! (:stats executor-data) (:stream tuple-info) time-delta)))) 


注意 到 Spout 的 fail 方 法 只 是 传人 了 MessageId 对 象 , 作者 认为 既然 已 经 在 pending 发 送 队 列 中 
保存 了 消息 内 容 , 为 什么 不 将 该 消息 直接 通过 Fail 方 法 返回 给 用 户 的 Spout 呢 ? 这 样 用 户 收 到 失败 
消息 后 便 可 更 方便 地 进行 重 传 。 
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10.3.8 Spouti E A X ER 
Spout 使 用 send-spout-msg 函 数 来 发 送 消 息 ， 其 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 


9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 


send-spout-msg (fn [out-stream-id values message-id out-task-id] 
(.increment emitted-count) 
(let [out-tasks (if out-task-id 
(tasks-fn out-task-id out-stream-id values) 
(tasks-fn out-stream-id values)) 
rooted? (and message-id has-ackers?) 
root-id (if rooted? (MessageId/generateId rand)) 
out-ids (fast-list-for [t out-tasks] (if rooted? 
(MessageId/generateId rand)))] 
(fast-list-iter [out-task out-tasks id out-ids] 
(let [tuple-id (if rooted? 
(MessageId/makeRootId root-id id) 
(MessageId/makeUnanchored)) 
out-tuple (TupleImpl. worker-context 
values 
task-id 
out-stream-id 
tuple-id)] 
(transfer-fn out-task 
out-tuple 
overflow-buffer) 
)) 
(if rooted? 
(do 
(.put pending root-id [task-id 
message-id 
{:stream out-stream-id :values values} 
(if (sampler) (System/currentTimeMillis))]) 
(task/send-unanchored task-data 
ACKER-INIT-STREAM-ID 
[root-id (bit-xor-vals out-ids) task-id] 
overflow-buffer)) 
(when message-id 
(ack-spout-msg executor-data task-data message-id 
{:stream out-stream-id :values values} 
(if (sampler) 0)))) 
(or out-tasks []) 
1] 


在 该 函数 中 , 其 中 各 个 形 参 的 含义 为 : out-stream-id 是 消息 的 Streamld; values 是 消息 内 容 ; 
message-id 是 消息 的 MessageId， 表 示 是 否 要 对 消息 进行 跟踪 ; out-task-id 则 是 消息 的 接收 端 
Taskld， 用 于 向 直接 流 发 送 消息 。 


口 


第 3~5 行 调用 tasks-fn 孙 数 来 获得 消息 的 目标 TaskId。tasks-fn 是 Task 的 主要 函数 , ES 
据 消 息 的 StreamId 和 消息 内 容 来 确定 哪些 Task 将 接收 该 流 的 消息 ,以 及 以 何 种 方式 来 接收 
该 流 的 消息 。 对 于 直接 分 组 方式 ， 其 作用 主要 是 检查 目标 out-task-id 是 否 以 直接 分 组 的 
方式 来 接收 消息 。 
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第 18~21 行 调用 transfer-fn 函 数 来 发 送 消息 。 该 函数 由 mk-executor-transfer-fn 函 数 创 
E^ 并 会 将 消息 发 送 至 Executor 的 发 送 队 列 中 。 
其 他 的 代码 与 消息 跟踪 相关 ， 请 参看 第 12 章 。 
前 面 提 到 的 mk-executor-transfer-fn 函 数 用 于 定义 消息 发 送 函 数 ， 其 参数 batch-transfer-> 
worker 对 应 于 Executor 的 输出 Disruptor Queue ， 其 代码 如 下 : 


1 (defn mk-executor-transfer-fn [batch-transfer->worker] 

2 (fn this 

3 ([task tuple block? ^List overflow-buffer] 

4 (if (and overflow-buffer (not (.isEmpty overflow-buffer))) 
5 (.add overflow-buffer [task tuple]) 

6 (try-cause 

7 (disruptor/publish batch-transfer-»worker [task tuple] block?) 
8 (catch InsufficientCapacityException e 

9 (if overflow-buffer 

10 (.add overflow-buffer [task tuple]) 

11 (throw e)) 

12 ))) 

13 ([task tuple overflow-buffer] 

14 (this task tuple (nil? overflow-buffer) overflow-buffer)) 
15 ([task tuple] 

16 (this task tuple nil) 

17 )) 


该 函数 存在 3 种 重 载 ， 主 要 区 别 在 于 是 否 对 发 送 的 消息 进行 缓存 。 

口 在 第 4 行 中 ， 若 overflow-buffer 非 空 ， 则 将 消息 放 和 人 其 中 ; 否则 通过 disruptor/publish 

方法 进行 发 送 。 

口 从 第 8~12 行 可 以 看 出 ， 当 Disruptor Queue x fH] A EAT, PR CT 9E AZ 3 HJ TH CA 
overflow-buffer 中 。overflow-buffer 是 一 个 临时 缓存 ， 当 Disruptor Queue 接 收 端 未 启动 或 
空间 不 足 时 ， 用 于 临时 存放 将 要 发 送 的 消息 。 第 4 行 的 overflow-buffer 非 空 ， 则 表明 该 异 
常 已 经 发 生 过 ，Disruptor Queue 中 空间 已 经 不 足 ， 此 时 消 ， 自 会 被 直接 放 入 overflow- buffer 
以 提高 效率 。 在 Spout 的 消息 循环 中， 会 优先 发 送 overflow-buffer 中 的 数据 。 


10.3.4 ”Spout 对 象 的 初始 化 
下 面 的 代码 用 于 调用 Executor 中 各 Spout 对 象 的 open 操 作 ， 其 中 open 方 法 只 会 被 调用 一 次 : 


33 If topology was started in inactive state, don't call (.open spout) until it's activated first. 
(while (not Q(:storm-active-atom executor-data)) 
(Thread/sleep 100)) 


(log-message "Opening spout " component-id ":" (keys task-datas)) 
(doseq [[task-id task-data] task-datas 
:let [^ISpout spout-obj (:object task-data) 
tasks-fn (:tasks-fn task-data) 
send-spout-msg (参考 前 面 讨论 )]] 


WON AU BPWN PP 
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10 (builtin-metrics/register-all (:builtin-metrics task-data) storm-conf (:user-context 
task-data)) 

11 (.open spout-obj 

12 storm-conf 

13 (:user-context task-data) 

14 (SpoutOutputCollector. 

15 (reify ISpoutOutputCollector 

16 (“List emit [this “String stream-id “List tuple “Object message-id] 

17 (send-spout-msg stream-id tuple message-id nil) 

18 ) 

19 (‘void emitDirect [this ^int out-task-id “String stream-id 

20 ‘List tuple “Object message-id] 

21 (send-spout-msg stream-id tuple message-id out-task-id) 

22 

23 (reportError [this error] 

24 (report-error error) 

25 20)) 

26 (reset! open-or-prepare-was-called? true) 

27 (log-message "Opened spout " component-id ":" (keys task-datas)) 


28 (setup-metrics! executor-data) 


29 


30 (disruptor/consumer-started! (:receive-queue executor-data)) 


a 第 2~3 行 进行 等 待 直到 Topology 处 于 活跃 状态 
口 第 6~25 行 对 Executor 中 的 每 一 个 Spouttt4 ÍT PRE 598 8-9 ÍT 3X 13 tasks-fn PK RU All 


send-spout-msgPÁZX, send-spout-msg ek 242 All Hitasks-fnPR BOK PET HpiTaskId, TEX 


到 Executor 中 的 每 一 个 Spout 都 定义 了 send-spout-msg 方 法 ， 这 是 由 于 消息 接收 端 TaskId 
可 能 会 与 当前 Task 相 关 。 例 如 , 直接 分 组 方式 中 , 消息 接收 端的 TaskId 以 及 当前 Task 是 预 


先 绑 定 的 。 类 似 地 ，send-spout-msg 还 需要 利用 tasks-fn 来 选择 接收 端 TaskId， 同 时 在 进 
行 消息 跟踪 时 记录 发 送 消息 的 TaskId， 故 Storm 将 这 些 图 数 定 义 为 Task 级 别 而 非 Executor 
共享 。 


a 第 11~25 行 依次 调用 Spout 对 象 的 open 回 调 方法 ， 同 时 实例 化 SpoutOutputCoLlector， 
要 调用 send-spout-msg 来 发 送 消 息 。 
a 第 30 行 调用 consumer-started! 函 数 打 开 接收 队列 。 由 于 在 open 函 数 被 调用 之 前 , 接收 队列 


它 主 


尚未 打开 , 故 最 好 不 要 在 Spout 的 open 函 数 中 发 送 消息 C 当然 即使 真 的 这 样 发 送 了 Storm 也 
会 对 此 时 发 送 的 消息 进行 缓存 处 理 )。 


10.3.5 ”消息 循环 


传人 async-loop 的 工厂 函数 被 调用 后 ， 


将 调用 该 函 
正常 情况 下 ， 
发 送 新 的 消息 


数 ， 从 第 39 行 该 函数 的 返回 值 为 0 可 以 看 出 ， 相 邻 两 次 函数 调用 之 间 是 没有 等 


会 返回 第 1~39 行 定义 的 函数 。 在 async-loop 循 环 体 中 , 


TH. 


该 函数 会 依次 执行 接收 队列 的 消息 、 重 发 之 前 未 成 功 发 送 的 消息 、 调 用 nextTuple 


息 ， 以 及 进行 流量 控制 等 一 系列 操作 。 下 面 来 看 这 个 函数 的 实现 : 
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1 (fn [] 

2 ;; This design requires that spouts be non-blocking 

3 (disruptor/consume-batch receive-queue event-handler) 

4 

5 ;; try to clear the overflow-buffer 

6 (try-cause 

7 (while (not (.isEmpty overflow-buffer)) 

8 (let [[out-task out-tuple] (.peek overflow-buffer)] 

9 (transfer-fn out-task out-tuple false nil) 

10 (.removeFirst overflow-buffer))) 

11 (catch InsufficientCapacityException e 

12 )) 

13 

14 (let [active? @(:storm-active-atom executor-data) 

15 curr-count (.get emitted-count) ] 

16 (if (and (.isEmpty overflow-buffer) 

17 (or (not max-spout-pending) 

18 (< (.size pending) max-spout-pending) )) 

19 (if active? 

20 (do 

21 (when-not @last-active 

22 (reset! last-active true) 

23 (log-message "Activating spout " component-id ":" (keys task-datas)) 
24 (fast-list-iter [^ISpout spout spouts] (.activate spout))) 
25 

26 (fast-list-iter [^ISpout spout spouts] (.nextTuple spout))) 

27 (do 

28 (when @last-active 

29 (reset! last-active false) 

30 (log-message "Deactivating spout " component-id ":" (keys task-datas)) 
31 (fast-list-iter [^ISpout spout spouts] (.deactivate spout) )) 
32 ;; TODO: log that it's getting throttled 

33 (Time/sleep 100)))) 

34 (if (and (= curr-count (.get emitted-count)) active?) 

35 (do (.increment empty-emit-streak) 

36 (.emptyEmit spout-wait-strategy (.get empty-emit-streak))) 

37 (.set empty-emit-streak O) 

38 )) 

39 0)) 


口 第 3 行 以 非 阻 塞 的 方式 对 接收 队列 中 的 消息 进行 处 理 。 
O 第 5~12 行 优先 发 送 overflow-buffer 中 的 数据 ( 由 于 Executor 中 发 送 消息 队列 已 满 , 数据 会 
被 缓存 在 overflow-buffer 中 )。 

O 在 第 16~18 行 中 ， 若 overflow-buffer 为 空 ， 并 且 pending 存 储 的 数据 少 于 max-spout-pending， 

或 者 未 设置 max-spout-pending， 最 后 需要 Topology 处 于 活跃 状态 ， 则 Spout 可 以 发 送 消息 。 

a 第 26 行 依次 调用 spout 的 nextTuple 回 调 方法 来 发 送 消 息 。nextTuple 会 利用 传人 的 
SpoutOutputCollector 的 emit 或 emitDirect 方 法 来 发 送 消息 ， 并 最 终 调 用 send-spout-msg 
函数 将 消息 发 送 到 Executor 的 消息 发 送 队 列 中 。send-spout-msg 函 数 会 更 新 emitted-count。 

O 在 第 28~33 行 中 ， 若 Topology 处 于 非 活跃 状态 ， 则 睡眠 100 毫 秒 。 
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O 在 第 34~38 行 中 ， 若 emitted-count 与 上 次 发 送 消息 的 curr-count 相 同 ， 则 表明 nextTuple 
函数 没有 发 送出 去 消息 ， 此 时 调用 spout-wait-strategy 的 emptyEmit 方 法 来 进行 处 理 。 默 
认 情 况 下 ， 我 们 会 根据 TOPOLOGY SLEEP SPOUT WAIT STRATEGY _TIME_MS 配 置 项 来 决定 睡眠 
mp], Any zee. 


iE 


10.4 Bolt 类 型 的 Executor 
Bolt 类 型 的 Executor 的 定义 跟 Spout 类 型 的 类 似 ， 下 面 我 们 来 详细 介绍 一 下 。 
10.4.1 准备 消息 循环 的 数据 


Bolt 类 型 的 Executor 的 消息 循环 数据 较 少 ， 主 要 是 定义 了 tuple-action-fn 函 数 (后 面 会 单独 
介绍 )， 该 函数 会 根据 Task[d 获 得 对 应 的 Bolt 对 象 并 调用 其 execute 方 法 。 相 关 代 码 如 下 : 


(let [execute-sampler (mk-stats-sampler (:storm-conf executor-data)) 
executor-stats (:stats executor-data) 
(:keys [storm-conf component-id worker-context transfer-fn report-error sampler 
open-or-prepare-was-called?]) executor-data 
rand (Random. (Utils/secureRandomLong)) 
tuple-action-fn], 


10.4.2 Bolt 输入 处 理 函 数 
Bolt 的 消息 处 理 较为 简单 ， 相 关 代码 如 下 所 示 ; 


1 tuple-action-fn (fn [task-id ^TupleImpl tuple] 

2 (let [stream-id (.getSourceStreamId tuple)] 

3 (condp = stream-id 

4 Constants/METRICS TICK STREAM ID (metrics-tick executor-data task-datas tuple) 
5 (let [task-data (get task-datas task-id) 

6 ^IBolt bolt-obj (:object task-data) 

7 user-context (:user-context task-data) 

8 sampler? (sampler) 

9 execute-sampler? (execute-sampler) 


10 now (if (or sampler? execute-sampler?) (System/currentTimeMillis))] 

11 (when sampler? 

12 (.setProcessSampleStartTime tuple now)) 

13 (when execute-sampler? 

14 (.setExecuteSampleStartTime tuple now)) 

15 (.execute bolt-obj tuple) 

16 (let [delta (tuple-execute-time-delta! tuple) ] 

17 (task/apply-hooks user-context .boltExecute (BoltExecuteInfo. tuple task-id 
delta) ) 

18 (when delta 

19 (builtin-metrics/bolt-execute-tuple! (:builtin-metrics task-data) 

20 executor-stats 


21 (.getSourceComponent tuple) 
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22 (.getSourceStreamId tuple) 

23 delta) 

24 (stats/bolt-execute-tuple! executor-stats 
25 (.getSourceComponent tuple) 

26 (.getSourceStreamId tuple) 

27 delta))))))] 


第 6 行 获得 该 Bolt 对 应 的 bolt-obj, 第 15 行 调用 bolt-obj 的 execute 回 调 方 法 。 其 他 处 理 逻 辑 都 
与 运行 统计 相关 ， 请 参考 第 13 章 和 第 14 章 。 


10.4.3 Bolt 的 消息 发 送 函 数 
Bolt 使 用 bolt-emit 函 数 来 发 送 消息 ， 其 代码 如 下 : 


1 bolt-emit (fn [stream anchors values task] 

2 (let [out-tasks (if task 

3 (tasks-fn task stream values) 

4 (tasks-fn stream values))] 

5 (fast-list-iter [t out-tasks] 

6 (let [anchors-to-ids (HashMap.)] 

7 (fast-list-iter [^TupleImpl a anchors] 

8 (let [root-ids (-> a .getMessageId .getAnchorsToIds .keySet)] 
9 (when (pos? (count root-ids)) 

1 


0 (let [edge-id (MessageId/generateId rand)] 
11 (.updateAckVal a edge-id) 

12 (fast-list-iter [root-id root-ids] 

13 (put-xor! anchors-to-ids root-id edge-id)) 
14 )))) 

15 (transfer-fn t 

16 (TupleImpl. worker-context 

17 values 

18 task-id 

19 stream 

20 (MessageId/makeId anchors-to-ids))))) 
21 (or out-tasks []))) 


第 2~4 行 获取 消息 接收 端的 TaskId 集 合 , 第 1$~20 行 调用 transfer-fn 函 数 发 送 消息 , 该 函数 与 
Spout 中 的 一 致 (差别 在 于 Bolt 不 使 用 overflow-buffer 缓 存 )。 其 他 的 代码 与 消息 跟踪 相关 ， 详 情 
请 参考 第 12 章 。 


10.4.4 ”Bolt 对 象 的 初始 化 
以 下 这 部 分 代码 主要 用 于 调用 Bolt 的 prepare 函 数 : 


1 ;; If topology was started in inactive state, don't call prepare bolt until it's activated first. 
2 (while (not @(:storm-active-atom executor-data)) 

3 (Thread/sleep 100)) 
4 
5 


(log-message "Preparing bolt " component-id ":" (keys task-datas)) 
6 (doseq [[task-id task-data] task-datas 
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7 :let [^IBolt bolt-obj (:object task-data) 
8 tasks-fn (:tasks-fn task-data) 
9 user-context (:user-context task-data) 
10 bolt-emit]] 
11 (builtin-metrics/register-all (:builtin-metrics task-data) storm-conf user-context) 
12 (.prepare bolt-obj 
13 storm-conf 
14 user-context 
15 (OutputCollector. 
16 (reify IOutputCollector 
17 (emit [this stream anchors values] 
18 (bolt-emit stream anchors values nil)) 
19 (emitDirect [this task stream anchors values] 
20 (bolt-emit stream anchors values task)) 
21 (^void ack [this ^Tuple tuple] 
22 (let [^TupleImpl tuple tuple 
23 ack-val (.getAckVal tuple) ] 
24 (fast-map-iter [[root id] (.. tuple getMessageId getAnchorsTolds) ] 
25 (task/send-unanchored task-data 
26 ACKER-ACK - STREAM- ID 
27 [root (bit-xor id ack-val)]) 
28 
29 (^void fail [this ^Tuple tuple] 
30 (fast-list-iter [root (.. tuple getMessageId getAnchors)] 
31 (task/send-unanchored task-data 
32 ACKER-FAIL-STREAM-ID 
33 [root]))) 
34 (reportError [this error] 
35 (report-error error) 
36 ))))) 


37 (reset! open-or-prepare-was-called? true) 
38 (log-message "Prepared bolt " component-id ":" (keys task-datas)) 
39 (setup-metrics! executor-data) 


40 


41 (let [receive-queue (:receive-queue executor-data) 


42 
43 


event-handler (mk-task-receiver executor-data tuple-action-fn)] 
(disruptor/consumer-started! receive-queue))) 


O 44247} FAmk-task-receiver KARIRI BA FI ES AL ER RA 


10.4.5 


Y 


~ 


主 消 


消息 循环 


口 第 7~10 行 主要 获取 Bolt 对 象 并 定义 相关 方法 。bolt-emit 方 法 用 于 向 Executor 的 消息 发 送 队 
列 中 发 送 消息 ， 是 其 中 最 重要 的 方法 ， 前 面 简要 介绍 过 。 
a 第 12~36 行 调用 Bolt 对 象 的 prepare 方 法 ， 同 时 实例 化 Bolt 对 象 的 OutputCollector 对 象 作 为 
prepare 方 法 的 传人 参数 ，0utputCollector 的 emit 方 法 将 调用 bolt-emit 函 数 来 发 送 消 , 
ack 及 fail 方 法 则 用 来 对 消息 进行 跟踪 。 这 里 ，ack 和 fail 方 法 中 采用 了 task.clj 的 
send-unanchored 方 法 向 Acker Bolt 的 相关 流 发 送 消息 ， 详 情 请 参考 第 12 章 。 


H 


US» 


息 循 环比 较 简 单 ， 它 调用 阻塞 方式 的 consume-batch-when-available 汤 数 对 接收 队列 中 
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的 消息 进行 处 理 ， 相 关 代码 如 下 : 
(fn [] 


(disruptor/consume-batch-when-available receive-queue event-handler) 
0) 


10.5 创建 Executor 
最 后 来 看 Worker 是 如 何 创建 一 个 Executor 的 ， 其 中 涉及 的 mk-executor 函 数 的 代码 如 下 : 


1 (defn mk-executor [worker executor-id] 
2 (let [executor-data (mk-executor-data worker executor-id) 
3 . (log-message "Loading executor " (:component-id executor-data) ":" (pr-str 


executor-id)) 


4 task-datas (-»» executor-data 

5 :task-ids 

6 (map (fn [t] [t (task/mk-task executor-data t)])) 

7 (into {}) 

8 (HashMap.)) 

9 _ (log-message "Loaded executor tasks " (:component-id executor-data) ":" (pr-str 
executor-id)) 

10 report-error-and-die (:report-error-and-die executor-data) 

11 component-id (:component-id executor-data) 

12 

13 ;; starting the batch-transfer-»worker ensures that anything publishing to that 
queue 

14 ;; doesn't block (because it's a single threaded queue and the caching/consumer 
started 

15 ;; trick isn't thread-safe) 

16 system-threads [(start-batch-transfer-»worker-handler! worker executor-data)] 

17 handlers (with-error-reaction report-error-and-die 

18 (mk-threads executor-data task-datas)) 

19 threads (concat handlers system-threads)] 

20 (setup-ticks! worker executor-data) 

21 

22 (log-message "Finished loading executor " component-id ":" (pr-str executor-id)) 

23 33 TODO: add method here to get rendered stats... have worker call that when heartbeating 

24 (xeify 

25 RunningExecutor 

26 (xender-stats [this] 

27 (stats/render-stats! (:stats executor-data))) 

28 (get-executor-id [this] 

29 executor-id ) 

30 Shutdownable 

31 (shutdown 

32 [this] 

33 (log-message "Shutting down executor " component-id ":" (pr-str executor-id)) 

34 (disruptor/halt-with-interrupt! (:receive-queue executor-data)) 

35 (disruptor/halt-with-interrupt! (:batch-transfer-queue executor-data)) 

36 (doseq [t threads] 


37 (.interrupt t) 
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38 (.join t)) 

39 

40 (doseq [user-context (map :user-context (vals task-datas)) ] 
41 (doseq [hook (.getHooks user-context)] 

42 (.cleanup hook))) 

43 (.disconnect (:storm-cluster-state executor-data)) 

44 (when @(:open-or-prepare-was-called? executor-data) 

45 (doseq [obj (map :object (vals task-datas))] 

46 (close-component executor-data obj))) 

47 (log-message "Shut down executor " component-id ":" (pr-str executor-id))) 
48 )) 


a 第 2 行 调用 mk-executor-data 来 创建 Executor 的 数据 。 
口 第 4~8 行 则 调用 mk-task 来 创建 Executor 中 每 个 Task 对 应 的 数据 。 
O 第 16 行 调用 start-batch-transfer->worker-handler! 方 法 启动 Executor 的 数据 发 送 线程 
口 第 17~18 行 调用 mk-threads 方 法 来 获得 Executor 的 主 循环 线程 ， 并 通过 with-error- 
reaction 宏 对 mk-threads 进 行 包 装 。 当 异常 发 生 时 ,调用 report-error-and-die 方 法 记录 
错误 并 退出 。 
a 第 25~29 行 实例 化 RunningExecutor 对 象 用 以 操作 Executor， 例 如 调用 stats/render-stats! 
函数 来 收集 Executor 的 运行 统计 等 。 
a 第 31~48 行 实例 化 Shutdownable， 用 于 退出 Executor 并 清理 相关 资源 ， 有 具体 的 操作 包括 : 
u 结束 Disruptor Queue 的 消息 循环 ; 
u 结束 Executor 中 启动 的 线程 ; 
m 清理 用 户 钓 子 的 数据 ; 
u 朵 [ 开 到 ZooKeeper 的 连接 ; 
u 依次 调用 Executor 中 Spout 或 Bolt 的 close 方 法 。 
这 些 操作 并 不 一 定 会 被 全 部 调用 。 


10.6 ”辅助 函数 介绍 
在 这 一 节 中 ， 我 们 介绍 一 下 Executor 中 用 到 的 一 些 重要 辅助 方法 。 


10.6.1 ŻAK Grouper žit 


获得 当前 组 件 中 一 个 流 的 所 有 接收 端 及 其 接收 方式 是 Executor 中 的 重要 算法 ， 这 是 tasks- 旬 函 
数 完成 各 种 操作 的 前 提 。 

outbound-components 孙 数 用 于 获取 从 组 件 到 某 一 个 流 的 分 组 函数 ，tasks-fn 函 数 通过 调用 该 
分 组 函数 便 可 获得 消息 的 目标 Task 集 合 。outbound-components 的 代码 如 下 : 


o 


1 (defn outbound-components 

2 "Returns map of stream id to component id to grouper" 
3  [^WorkerTopologyContext worker-context component-id] 
4  (-» (.getTargets worker-context component-id) 

5 clojurify-structure 
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6 (map (fn [[stream-id component->grouping]] 

7 [stream-id 

8 (outbound-groupings 

9 worker-context 

10 component-id 

11 stream-id 

12 (.getComponentOutputFields worker-context component-id stream-id) 
13 component-»grouping)])) 

14 (into {}) 

15 (HashMap.))) 


a 第 4 行 调用 WorkerTopologyContext 对 象 的 getTargets 方 法 得 到 一 个 哈 希 表 ， 该 哈 希 表 的 键 
为 当前 组 件 所 对 应 的 流 ， 值 也 为 一 个 哈 硕 表 ， 用 于 记录 目标 组 件 以 何 种 方式 从 该 流 接收 
数据 。 

a 第 8 行 调用 outbound-groupings 函 数 通过 Thrift 类 型 的 分 组 方式 来 获得 分 组 函数 。 

outbond-groupings 函 数 的 定义 如 下 : 


1 (defn- outbound-groupings [^WorkerTopologyContext worker-context this-component-id stream-id 
out-fields component-»grouping] 


2 (-»» component-»grouping 

3 (filter-key #(-> worker-context 

4 (.getComponentTasks %) 
5 count 

6 pos?)) 

7 (map (fn [[component tgrouping]] 

8 [component 

9 (mk-grouper worker-context 
10 this-component-id 

11 stream-id 

12 out- fields 

13 tgrouping 

14 (.getComponentTasks worker-context component) 
15 1) 

16 (into {}) 

17 (HashMap.))) 


口 第 3~6 行 对 目标 组 件 进行 过 滤 , 若 组 件 对 应 的 TaskId 集 合 为 空 , 则 会 被 过 滤 掉 。filter-key 
函数 的 功能 是 对 一 个 哈 希 表 中 的 键 进行 过 滤 。 
a 第 7~15 行 利用 map 函 数 对 组 件 及 其 分 组 方式 进行 处 理 ， 调 用 mk-grouper 函 数 来 产生 分 组 也 
数 ， 并 最 终 返 回 一 个 保存 有 从 组 件 到 分 组 函数 的 映射 关系 的 哈 希 表 。 
mk-grouper 哨 数 是 Executor 的 核心 方法 。 它 会 返回 一 个 函数 , 该 函数 返回 一 个 TaskId 集 合 , fV 
表 消 息 发 送 的 目的 Task 和 集合。mk-grouper 的 代码 如 下 : 


1 (defn- mk-grouper 


2 "Returns a function that returns a vector of which task indices to send tuple to, or just a 
single task index." 
3 [^WorkerTopologyContext context component-id stream-id “Fields out-fields thrift-grouping 


^List target-tasks] 
4 (let [num-tasks (count target-tasks) 
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5 random (Random. ) 

6 target-tasks (vec (sort target-tasks))] 

7 (condp = (thrift/grouping-type thrift-grouping) 

8 : fields 

9 (if (thrift/global-grouping? thrift-grouping) 

10 (fn [task-id tuple] 

11 ;; It's possible for target to have multiple tasks if it reads multiple 

sources 

12 (first target-tasks)) 

13 (let [group-fields (Fields. (thrift/field-grouping thrift-grouping))] 

14 (mk-fields-grouper out-fields group-fields target-tasks) 

15 )) 

16 :all 

17 (fn [task-id tuple] target-tasks) 

18 :shuffle 

19 (mk-shuffle-grouper target-tasks) 

20 :local-or-shuffle 

21 (let [same-tasks (set/intersection 

22 (set target-tasks) 

23 (set (.getThisWorkerTasks context)))] 

24 (if-not (empty? same-tasks) 

25 (mk-shuffle-grouper (vec same-tasks)) 

26 (mk-shuffle-grouper target-tasks))) 

27 :none 

28 (fn [task-id tuple] 

29 (let [i (mod (.nextInt random) num-tasks)] 

30 (.get target-tasks i) 

31 )) 

32 :custom-object 

33 (let [grouping (thrift/instantiate-java-object (.get custom object 
thrift-grouping))] 

34 (mk-custom-grouper grouping context component-id stream-id target-tasks)) 

35 :custom-serialized 

36 (let [grouping (Utils/deserialize (.get custom serialized thrift-grouping))] 

37 (mk-custom-grouper grouping context component-id stream-id target-tasks)) 

38 :direct 

39 :direct 

40 ))) 


口 第 4 行 和 第 6 行 分 别 获得 与 目标 组 件 对 应 的 Task 的 数目 以 及 排列 后 的 列表 ,它们 将 作为 计算 


目标 Task 的 函数 输 


全 入 。 不 过 某 些 分 组 方式 只 需要 目标 组 件 的 Task 数 目 即 可 ， 例 如 


ShuffleGrouping 操 作 。 


O 第 7 行 针对 Thrift 类 3 


型 的 不 同 分 组 方式 分 别 构建 分 组 函数 。 


下 面 我 们 来 详细 介绍 Storm 提 供 的 几 种 分 组 方式 。 


1. 字段 分 组 
该 分 组 方式 首先 通过 


消息 中 与 分 组 字段 名 列表 对 应 的 值 计算 得 到 一 个 哈 希 值 , 然后 将 该 喻 希 


值 模 除 目标 节点 的 个 数 ， 选 出 这 条 消息 的 目标 节点 。 在 这 种 分 组 方式 下 ,每 条 消息 只 会 到 达 某 一 
个 目标 节点 ， 相 关 代码 如 下 : 
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1 (defn- mk-fields-grouper [^Fields out-fields ^Fields group-fields ^List target-tasks] 
2 (let [num-tasks (count target-tasks) 

3 task-getter (fn [i] (.get target-tasks i))] 

4 (fn [task-id ^List values] 

5 (-» (.select out-fields group-fields values) 

6 tuple/list-hash-code 

7 (mod num-tasks) 

8 task-getter)))) 


第 3 行 定 义 一 个 函数 task-getter， 它 根据 下 标 从 target-tasks 中 取出 实际 的 TaskId。 第 4~8 行 定 
义 了 实际 的 分 组 函数 ， 它 实际 上 调用 消息 (Java List 对 象 ) 的 hashCode 方 法 得 到 一 个 数值 并 抹 除 
接收 端 Task 的 数目 ， 从 而 获得 目标 Task 的 索引 。1ist-hash-code 困 数 的 代码 如 下 : 


(defn list-hash-code [^List alist] 
(.hashCode alist)) 


这 里 要 注意 的 是 : 如 果 List 中 的 元 素 为 数组 ， 此 时 的 哈 希 值 实 际 上 是 按照 数组 地 址 而 非 具 体 
数据 来 进行 计算 的 ,这 可 能 会 导致 内 容 相同 的 消息 无 法 到 达 相 同 的 节点 。 这 种 情况 下 ,用 户 应 使 
用 基于 数据 而 非 地 址 的 哈 希 方法 。 

如 果 传 人 的 分 组 字段 列表 为 空 ,第 6 行 代码 得 到 的 哈 希 值 将 为 1, 于 是 所 有 的 发 送 消 息 都 会 被 
送 到 一 个 节点 上 去 ， 该 分 组 方式 就 演化 成 了 全 局 分 组 (Global Grouping )。 不 过 哈 希 值 1 实 际 上 表 
示 目 标 节 点 中 的 第 2 个 节点 , 这 可 能 会 导致 误解 或 者 错误 ,因此 最 好 不 要 传人 空 的 分 组 字段 列表 。 

2. 随机 分 组 

该 分 组 方式 表示 将 输入 消息 随机 地 分 配 到 目标 节点 上 ， 相 关 代码 如 下 : 


1 (defn- mk-shuffle-grouper [^List target-tasks] 

2 (let [choices (rotating-random-range target-tasks)] 
3 (fn [task-id tuple] 

4 (acquire-random-range-id choices)))) 

5 

6 (defn rotating-random-range [choices] 

7 (let [rand (Random.) 

8 choices (ArrayList. choices)] 

9 (Collections/shuffle choices rand) 

10 [(MutableInt. -1) choices rand])) 

11 

12 (defn acquire-random-range-id [[^MutableInt curr ^List state ^Random rand]] 
13 (when (>= (.increment curr) (.size state)) 

14 (.set curr 0) 

15 (Collections/shuffle state rand)) 

16 (.get state (.get curr))) 


a 第 1~4 行 定义 随机 分 组 函数 ， 该 函数 只 需 传 人 目标 的 节点 列表 。 该 函数 会 调用 rotating- 
random-range 进 行 初始 化 , 即 通过 在 函数 体 中 不 断 调 用 函数 acquire-Tandom-range-id 返 回 
所 有 目标 节点 的 TaskId。 这 个 算法 保证 了 每 一 个 节点 都 有 均等 的 机 会 收 到 新 消息 ,同时 它 
也 具有 较 好 的 随机 性 


T 


o 
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a 第 6~10 行 定义 了 一 个 通用 函数 rotating-random-range， 该 函数 会 调用 输入 集合 的 搅乱 操 

作 ， 返 回 值 为 全 1 搅乱 过 后 的 集合 ， 一 个 随机 数 } 。 

口 第 12~16 行 定义 了 一 ji uU MM nie 其 输入 为 上 一 个 函数 的 输出 ， 
输出 为 变量 curr 指 示 的 元 素 。 该 函数 会 自 增 curr, 并 判断 它 是 否 大 于 目标 节点 集合 的 大 小 ， 
知 超 出 了 范围 就 将 其 重 置 为 0， 和 目标 节点 集合 ， 这 样 增加 了 更 多 的 随 
机 性 。 

3. 全 部 分 组 
该 分 组 方式 表示 ， 所 有 的 接收 端 节点 都 会 收 到 待 发 消息 ， 相 关 代码 如 下 : 
(fn [task-id tuple] target-tasks) 
4. 无 分 组 
在 该 分 组 方式 下 ，Storm 将 随机 选择 一 个 目标 节点 ， 并 将 所 有 的 消息 都 将 发 送 到 该 节点 上 ， 
相关 代码 如 下 : 
(fn [task-id tuple] 
(let [i (mod (.nextInt random) num-tasks)] 

(.get target-tasks i) 

)) 
在 Topology 启 动 后 ， 上 面 的 代码 将 通过 利用 一 个 随机 数 模 除 目标 Task 数 的 手段 来 选择 接收 节 

点 ， 之 后 要 发 送 的 消息 都 将 发 送 至 该 节点 。 

5. 直接 分 组 

在 这 种 分 组 方式 下 ,消息 将 直接 发 送 到 某 一 个 特定 节点 , 这 在 传递 控制 信息 时 非常 有 用 。 在 
事务 Topology 中 经 常 可 以 看 到 这 种 分 组 方式 。 

6. 自 定义 分 组 

这 是 用 户 自 定 义 的 分 组 方法 。 用 户 需 要 实现 下 面 的 CustomStreamGrouping 接 口 来 完成 自 
定义 : 


public interface CustomStreamGrouping extends Serializable { 


* Tells the stream grouping at runtime the tasks in the target bolt. 
* This information should be used in chooseTasks to determine the target tasks. 


* It also tells the grouping the metadata on the stream this grouping will be used on. 
*/ 
void prepare(WorkerTopologyContext context, GlobalStreamId stream, List«Integer» targetTasks); 


* This function implements a custom stream grouping. It takes in as input 
* the number of tasks in the target bolt in prepare and returns the 

* tasks to send the tuples to. 
* 
* 


@param values the values to group on 
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List<Integer> chooseTasks(int taskId, List«Object» values); 


} 


ix H Is] preparer PFA HIRT AREA DUC RU ZELPERTU f ER. EU AA Bem HU TE 
算 提 供 上 下 文 。 

chooseTasks 函 数 将 在 运行 时 调用 ， 其 参数 为 当前 的 TaskId 和 消息 内 容 。 

那么 用 户 自 定 义 的 分 组 函数 是 如 何 集成 到 storm 中 的 呢 ? mk-custom-grouper 函 数 将 定义 一 个 
分 组 函数 ， 该 分 组 函数 的 实现 是 基于 用 户 自 定 义 的 实现 了 CustomStreamGrouping 接 口 的 类 ， 其 代 
码 如 下 : 


1 (defn- mk-custom-grouper [^CustomStreamGrouping grouping ^WorkerTopologyContext context ^String 
component-id ^String stream-id target-tasks] 
(.prepare grouping context (GlobalStreamId. component-id stream-id) target-tasks) 
(fn [task-id ^List values] 
(.chooseTasks grouping task-id values) 


)) 
a 第 2 行 调用 用 户 实现 的 prepare 方 法 ， 传 人 当前 的 GlobalStreamId 及 目标 Task 列 表 ， 以 准备 
分 组 函数 的 上 下 文 。 
a 第 3~5 行 定义 并 返回 一 个 函数 ， 该 函数 将 调用 用 户 实现 的 chooseTasks 来 选择 一 个 目标 节点 。 
7. Local_or_Shuffle Grouping 
这 种 分 组 方式 会 首先 选择 将 消息 发 送 到 属于 同一 Worker 的 目标 Task 上 。 由 于 属于 同一 进程 空 
间 ， 被 发 送 的 消息 将 不 需要 经 过 ZMQ 及 网 络 来 传输 ， 而 是 通过 Disruptor Queue 在 线程 之 间 传 输 ， 
这 样 性 能 会 得 到 提高 ， 相 关 代码 如 下 : 


(let [same-tasks (set/intersection 
(set target-tasks) 
(set (.getThisWorkerTasks context)))] 
(if-not (empty? same-tasks) 
(mk-shuffle-grouper (vec same-tasks)) 
(mk-shuffle-grouper target-tasks))) 


如 果 没 有 找到 这 样 的 Task， 就 通过 随机 分 组 方式 来 选择 消息 的 接收 端 。 
10.6.2” 带 流量 控制 的 错误 报告 方法 


Storm 会 将 Executor 产 生 的 错误 记录 到 ZooKeeper 中 ， 而 Nimbus 通 过 访问 ZooKeeper 获 得 该 数 
据 并 将 其 显示 在 StormUI 上 。 过 于 频繁 以 及 过 多 的 错误 报告 都 会 对 ZooKeeper 造 成 影响 , 因此 Storm 
采用 了 相应 的 控制 策略 ， 即 限制 同一 时 间 段 内 报告 错误 的 数量 ， 并 对 ZooKeeper 中 老 数据 进行 清 
理 ， 相 关 代码 如 下 : 


uq u€uNP. 


1 (defn throttled-report-error-fn [executor] 

2 (let [storm-conf (:storm-conf executor) 

3 error-interval-secs (storm-conf TOPOLOGY-ERROR-THROTTLE - INTERVAL - SECS) 
4 max-per-interval (storm-conf TOPOLOGY-MAX-ERROR-REPORT -PER- INTERVAL) 

5 interval-start-time (atom (current-time-secs)) 

6 interval-errors (atom 0) 
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7 ] 

8 (fn [error] 

9 (log-error error) 

10 (when (> (time-delta @interval-start-time) 

11 error-interval-secs) 

12 (reset! interval-errors 0) 

13 (reset! interval-start-time (current-time-secs))) 

14 (swap! interval-errors inc) 

15 

16 (when (<= @interval-errors max-per-interval) 

17 (cluster/report-error (:storm-cluster-state executor) (:storm-id executor) (:component-id 
executor) error) 

18 )))) 


O 第 3 行 中 error-interal-secs 的 值 是 从 Storm 的 配置 项 获得 的 ， 默 认为 10 秒 钟 。 第 4 行 的 
max-per-interval 也 是 从 Storm 的 配置 项 获得 的 ， 默 认 值 为 5。 这 两 个 参数 的 含义 为 10 秒 钟 
最 多 可 以 报告 错误 5 次 。 

a 第 8~18 行 定义 错误 报告 函数 。 第 9 行 首先 对 错误 进行 日 志 记 录 。 若 当前 时 间 已 经 超出 了 
error-interval-secs, ， 则 重新 开始 一 个 新 的 统计 区 间 ， 并 将 interval-errors 重 置 为 0。 第 17 
行 调用 cluster/report-error 将 错误 记录 到 ZooKeeper 中 ,其 中 ,report-error 方 法 的 定义 如 下 : 

口 第 2 行 获得 ZooKeeper 中 存储 错误 的 路 径 path， 其 默认 值 为 /storm/errors/<storm-id>/ 

<component-id>。 可 以 看 出 ， 错 误 是 按照 组 件 来 分 别 存 储 的 。 

第 3 行 构 建 数据 ，:time-secs 为 当前 的 时 间 ，:error 为 异常 的 错误 栈 。 

a 第 4~5 行 创建 父 节 点 以 及 用 于 存储 本 次 错误 的 ZooKeeper 节 点 , 其 中 节点 为 Sequential 类 型 。 

a 第 6~9 行 获得 该 组 件 对 应 的 错误 列表 ,然后 移 除 最 近 的 10 条 错误 信息 ， 并 将 剩余 的 错误 信 

息 保 存 到 to-kill 变 量 中 。 第 10~11 行 将 to-kill 数 据 从 ZooKeeper 中 清理 掉 。 于 是 ， 

ZooKeeper 始 终 保 存 了 每 一 个 组 件 最 近 的 10 条 错误 消息 。 实 际 上 ， 我 认为 这 里 应 该 再 设置 

一 个 时 间 窗 口 ， 将 更 为 久远 的 错误 消息 也 清除 掉 。 


1 (report-error [this storm-id component-id error] 

2 (let [path (error-path storm-id component-id) 

3 data {:time-secs (current-time-secs) :error (stringify-error error)} 

4 _ (mkdirs cluster-state path) 

5 . (create-sequential cluster-state (str path "/e") (Utils/serialize data)) 
6 to-kill (-»» (get-children cluster-state path false) 

7 (sort-by parse-error-path) 

8 reverse 

9 (drop 10))] 
10 (doseq [k to-kill] 
11 (delete-node cluster-state (str path "/" k))))) 


10.6.3 触发 系统 Ticks 


setup-ticks! 函数 用 来 定期 向 该 Execturor 的 接收 消息 队列 发 送 Tick 消 息 。Executor 在 收 到 了 T : 
ck 消息 之 后 ， 就 会 执行 发 送 队 列 的 超时 操作 。 因 此 ，setup-ticks! 主要 用 于 对 Spout 节 点 发 送出 


10.6 ”辅助 函数 介绍 195 


去 的 消息 进行 超时 操作 ， 相 关 代码 如 下 : 


1 (defn setup-ticks! [worker executor-data] 

2 (let [storm-conf (:storm-conf executor-data) 

3 tick-time-secs (storm-conf TOPOLOGY-TICK-TUPLE-FREQ-SECS) 

4 receive-queue (:receive-queue executor-data) 

5 context (:worker-context executor-data)] 

6 (when tick-time-secs 

7 (if (and (not (storm-conf TOPOLOGY-ENABLE-MESSAGE-TIMEOUTS) ) 
8 (= :spout (:type executor-data))) 

9 (log-message "Timeouts disabled for executor 
Hl 


" 


(:executor-id executor-data)) 


0 (schedule-recurring 

11 (:user-timer worker) 

12 tick-time-secs 

13 tick-time-secs 

14 (fn [] 

15 (disruptor/publish 

16 receive-queue 

17 [[nil (TupleImpl. context [tick-time-secs] -1 
Constants/SYSTEM TICK STREAM ID)]] 

18 ))))))) 


口 在 第 3~5 行 中 ， 配 置 项 TOPOLOGY-TICK-TUPLE-FREQ-SECS 用 来 控制 向 _system 流 以 及 _ tick 
流 发 送 消 息 的 频率 ，tick-time-secs 用 来 保存 该 频率 值 。receive-queue 为 Executor 对 应 的 
接收 Disruptor Queue ，context 为 WorkerTopologyContext 对 象 。 可 以 看 出 ，Tick 消 息 只 发 送 
到 本 地 Worker， 并 不 能 被 其 他 Worker 的 Executor 收 到 。 

O 在 第 6 行 中 ， 若 设置 tick-time-secs， 则 开始 设置 系统 的 Tick 消 息 。 

O 在 第 7~9 行 中 ， 若 该 节点 为 Spout 节 点 并 且 未 设置 消息 超时 ， 则 打印 消息 并 退出 。 参 数 
TOPOLOGY-ENABLE-MESSAGE-TIMEOUTS 主 要 用 于 调试 模式 ， 由 于 超时 的 消息 会 给 系统 调试 带 
来 额外 的 复杂 性 ， 因 此 可 在 调试 过 程 中 暂时 关闭 消息 的 超时 操作 。 当 Spout 收 到 Tick 消 息 
时 ， 可 以 对 缓存 在 pending 对 象 中 的 数据 进行 超时 操作 。 

口 第 10~18 行 利用 Worker 定 义 的 用 户 计时 器 以 tick-time-secs 为 间隔 设置 计时 器 。 第 14~18 行 定 
义 计 时 器 的 回调 函数 ， 并 向 receive-queue 中 发 送 一 条 消息 。 从 第 17 行 可 以 看 出 ， 该 消息 对 
应 的 TaskId 为 nil ， 表 示 该 Executor 中 所 有 的 Task 都 会 收 到 该 消息 ; 消息 的 内 容 为 
tick-time-secs; -1 表示 系统 TaskId; 最 后 一 项 表示 该 消息 会 被 发 送 到 SYSTEM TICK_STREAMID。 
Executor 在 创建 DisruptorQueue 的 处 理 器 时 ， 若 消息 的 TaskId 为 niL，Executor 将 发 送 消息 到 其 

所 有 Task 的 tuple-action-fn， 相 关 代码 如 下 : 


1 (defn mk-task-receiver [executor-data tuple-action-fn] 

2 (let [^KryoTupleDeserializer deserializer (:deserializer executor-data) 

3 task-ids (:task-ids executor-data) 

4 debug? (= true (-» executor-data :storm-conf (get TOPOLOGY-DEBUG))) 
5 ] 

6 (disruptor/clojure-handler 

7 (fn [tuple-batch sequence-id end-of-batch?] 

8 (fast-list-iter [[task-id msg] tuple-batch] 
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10. 


9 (let [^TupleImpl tuple (if (instance? Tuple msg) msg (.deserialize 
deserializer msg))] 

10 (when debug? (log-message "Processing received message " tuple)) 

11 (if task-id 

12 (tuple-action-fn task-id tuple) 

13 33 null task ids are broadcast tuples 

14 (fast-list-iter [task-id task-ids] 

15 (tuple-action-fn task-id tuple) 

16 )) 

17 )))))) 


O 第 2~5$ 行 获得 该 Executor 对 应 的 Taskld 列 表 以 及 消息 的 反 序 列 化 器 ， 默 认为 KryoTuple 
Deserializer 类 型 。 若 设置 ToPO0LOGY-DEBUG 为 true， 系 统 将 打印 每 一 条 其 收 到 和 发 送 的 消息 。 
a 第 6~17 行 实现 DisruptorQueue 的 消息 处 理 回 调 函 数 。tuple-batch 中 含有 收 到 的 一 组 消息 , 


其 消息 格式 为 [task-id, msg]。 第 9 行 调用 反 序 列 化 器 将 msg 反 序列 化 为 TupleImpl 对 象 。 第 11 
行 根 据 是 否 已 设置 task-id 来 决定 该 消息 是 发 送 给 某 一 个 TaskId 还 是 发 送 到 该 Executor 中 


所 有 Taskld。 


O 发 送 到 SYSTEM-TICK-STREAM-ID 流 的 消息 为 Tick 消 息 ，Task 收 到 Tick 消 息 后 ， 将 调用 


metrics-tickPE ZI A JH s 
7 小 结 


Executor 中 的 通信 关系 如 图 10-1 所 示 。 


ore 
‘send-spout -ms; 

ou 
lextTuple 


接收 队列 ey 


batch-transfer-» 
worker-handler! 
lom 


tuple-action| Execute 
-fn Bot-emit 


Emit/Ack/Fail 


Bolt 


发 送 队 列 


接收 队列 
batch-transfer-» 
worker-handlerl 


transfer-fn 


Worker 3X BAJI] | 


ZMQ 


图 10-1 ”Executor 的 架构 示意 图 
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下 面 简 要 介绍 一 下 : 

O Worker 从 ZMQ 收 到 消息 后 ， 会 按照 TaskId 将 消息 分 发 到 Executor 的 消息 接收 队列 中 。 

口 Executor 的 主 消息 循环 负责 处 理 消息 并 将 产生 的 消息 发 送 到 Executor 的 消息 发 送 队 列 中 。 

O 每 个 Executor 都 有 一 个 发 送 线程 用 以 监听 发 送 队 列 ， 它 会 将 发 送 队 列 中 的 消息 发 送 到 
Worker 的 消息 发 送 队列 或 者 其 他 Executor 的 接收 队列 中 。Worker 中 的 所 有 Executor 会 共享 
Worker 的 消息 发 送 队 列 。 


Task 


Storm 中 的 Task 是 最 小 的 执行 单位 。 与 Worker、Executor 分 别 对 应 于 进程 和 线程 不 同 ，Task 只 
是 逻辑 上 的 执行 单位 , 它 需 要 寄 身 于 Executor 中 完成 运行 。 一 个 Executor 可 以 含有 多 个 Task。 用 户 
定义 的 Spout 和 Bolt 对 象 都 会 被 放置 在 Task 上 。 当 Executor 收 到 属于 某 一 个 Task 的 消息 时 ， 就 会 调 
用 与 该 Task 对 应 的 Spout 或 Bolt 对 象 的 相关 方法 进行 处 理 。 


11.1 Task 的 上 下 文 对 象 


TopologyContext 对 象 为 Task 的 执行 提供 了 上 下 文 环 境 ， 它 实际 上 给 出 了 诸如 Topology 的 结 
构 、 流 的 定义 等 与 Topology 相 关 的 信息 。 


11.1.1 TopologyContext 


TopologyContext 类 继承 自 WorkerTopologyContext， 它 对 应 于 某 一 个 Task 运 行 的 上 下 文 Bolt 的 
prepare 方 法 以 及 Spout 的 open 方 法 均 会 传 入 该 类 的 对 象 。 该 类 的 代码 如 下 : 
public class TopologyContext extends WorkerTopologyContext implements IMetricsContext { 
private Integer taskId; 
private Map«String, Object» taskData = new HashMap<String, Object>(); 
private List«ITaskHook» hooks = new ArrayList<ITaskHook>(); 
private Map«String, Object» _executorData; 


private Map«Integer,Map«Integer, Map<String, IMetric»»»  registeredMetrics; 
private clojure.lang.Atom  openOrPrepareWasCalled; 


下 面 简 要 介绍 该 类 中 的 成 员 变 量 。 

口 _taskId 为 该 上 下 文 对 象 对 应 的 TaskId。 

口 _taskData 为 该 Task 共 享 的 数据 。 

口 _executorData 为 Task 所 在 Executor 共 享 的 数据 ， 用 于 在 属于 同一 Executor 的 Task 之 间 共 享 

数据 。 

口 _hooks 是 Storm 为 用 户 提供 的 一 种 扩展 机 制 。 用 户 可 以 为 Bolt 或 者 Spout 对 象 添 加 相应 的 回 
调 钩子 , 当 特 定 的 事件 发 生 时 , 钧 子 方法 将 被 调用 .TopologyContext 对 象 采用 addTaskHooks 
来 添加 一 个 钩子 , 利用 getHooks 获 得 钩子 回调 函数 。 这 样 , 用 户 便 可 更 加 灵活 地 进行 一 些 
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运行 时 统计 工作 了 。Executor 会 在 适当 的 时 机 调用 这 些 钩 子 方法 。 这 里 涉及 的 ITaskHook 
接口 的 定义 如 下 : 


public interface ITaskHook ( 
void prepare(Map conf, TopologyContext context); 
void cleanup(); 
void emit(EmitInfo info); 
void spoutAck(SpoutAckInfo info); 
void spoutFail(SpoutFailInfo info); 
void boltExecute(BoltExecuteInfo info); 
void boltAck(BoltAckInfo info); 
void boltFail(BoltFailInfo info); 
} 


例如 对 于 某 一 个 Bolt 节 点 , 用 户 可 以 实现 boltExecute 方 法 , 该 方法 传人 的 参数 为 BoltExecute 
Info 对 象 ， 其 中 含有 执行 的 消息 、taskId 以 及 执行 时 间 等 信息 ， 用 户 可 以 根据 这 些 信 息 完成 一 些 
自 定义 功能 。 目 前 ， 这 个 功能 的 用 处 还 不 多 。BoltExecuteInfo 类 的 定义 如 下 : 


public class BoltExecuteInfo { 
public Tuple tuple; 
public int executingTaskId; 
public Long executeLatencyMs; // null if it wasn't sampled 


} 

回 到 前 面 TopologyContext 的 定义 中 ， 这 里 的 registeredMetrics 和 _openOrpPrepareWasCalled 
主要 用 于 系统 的 内 置 统计 信息 中 。 例 如 ， 在 SystemBolt 中 注册 的 许多 与 Task 所 在 Worker 相 关 的 信 
息 就 属于 这 类 内 置 统计 信息 。 

接 下 来 我 们 讨论 TopologyContext 的 父 类 中 所 含有 的 数据 。 


11.1.2 GeneralTopologyContext 


GeneralTopologyContext 类 表示 Topology 的 上 下 文 环境 ， 它 提供 较 多 的 工具 方法 来 方便 获得 
Topology 的 结构 信息 。 该 类 的 定义 如 下 : 


public class GeneralTopologyContext implements JSONAware { 
private StormTopology _topology; 
private Map«Integer, String» taskToComponent; 
private Map<String, List«Integer»» _componentToTasks; 
private Map«String, Map«String, Fields»»  componentToStreamToFields; 
private String stormId; 
protected Map _stormConf; 


} 


下 面 简要 介绍 各 个 成 员 变 量 的 含义 。 
口 _topology 为 Thrift 生 成 的 storm Topology 类 型 的 对 象 ， 其 中 含有 Bolt 和 Spout 的 输入 输出 等 
信息 


JU O 


口 _taskToComponent 为 从 TaskId 到 组 件 ID 的 映射 。 
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口 _componentToTasks 为 从 组 件 ID 到 其 对 应 的 Task 集 合 的 映射 。 

口 _componentToStreamToFields 为 从 组 件 到 每 个 输出 流 的 模式 的 映射 。 
口 stormId 和 _stormConf 分 别 表 示 Topology 的 id 和 配置 项 。 
GeneralTopologyContext 中 定义 的 主要 工具 函数 如 表 11-1 所 示 。 


表 11-1 GeneralTopologyContext 的 工具 函数 


工具 函数 Hoo ox 
String getComponentId(int taskId) 根据 taskId 获 得 其 所 在 组 件 的 名 字 
Set«String» getComponentStreams(String componentId) 根据 组 件 名 字 获 得 该 组 件 对 应 的 输出 流 
List<Integer> getComponentTasks(String componentId) 根据 组 件 名 字 获 得 其 TaskId 的 集合 
Fields getComponentOutputFields(String componentId， 根据 组 件 ID 以 及 流 序 号 获得 该 流 的 模式 
String streamId) 
Fields getComponentOutputFields(Global StreamId id) 返回 值 同 上 。 

利用 组 件 ID 以 及 流 ID 可 以 构建 GlobalStreamId 对 象 


Map«GlobalStreamId, Grouping» getSources (String 获得 组 件 的 输入 。 根 据 组 件 序 号 获得 该 组 件 输入 的 
componentId) GlobalStreamId 以 及 分 组 方式 


Map<String, Map<String, Grouping»» get Targets(String ”获取 输出 节点 ， 键 为 当前 组 件 的 输出 流 序号 ， 值 为 目标 节点 
componentId) 的 组 件 ID 以 及 分 组 方式 

Map<Integer, String» getTaskTo Component() 返回 从 Task 到 组 件 的 映射 关系 

Set<String> getComponentIds() 获得 所 有 的 组 件 ID 集合 

int maxTopologyMessageTimeout() 获取 Topology 的 最 大 超时 时 间 ， 由 TOPOLOGY_ MESSAGE TIMEOUT | 


SECS 参 数 得 到 ， 根 据 Topology 的 配置 文件 以 及 各 个 Spout 节 点 
单独 设置 的 最 大 值 计算 获得 


在 上 述 工具 函数 ，getSources 和 getTargets 分 别 用 来 获取 一 个 组 件 的 输入 及 输出 ， 是 其 中 万 
为 重要 的 方法 。 


11.1.3 WorkerTopologyContext 


WorkerTopologyContext 类 继承 自 GeneralTopologyContext。 顾 名 思 义 ， 它 是 Storm 中 Worker 运 
行 的 上 下 文 环境 ， 也 即 Executor 中 的 共享 环境 。 该 类 的 实现 代码 如 下 : 


public class WorkerTopologyContext extends GeneralTopologyContext { 
public static final String SHARED EXECUTOR = "executor"; 
private Integer _workerPort; 
private List<Integer> _workerTasks; 
private String _codeDir; 
private String _pidDir; 
Map<String, Object> _userResources; 
Map<String, Object> _defaultResources; 
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口 _workerPort 为 该 Worker 所 对 应 的 端口 号 ， 用 于 ZMQ 传 输 数 据 等 。 

口 _workerTasks 为 该 Worker 上 执行 的 Task 和 集合 。 

口 _codeDir 为 第 三 方 代码 的 目录 ， 是 启动 其 他 语言 程序 的 工作 目录 具体 内容 为 

$StormData\supervison\stormdist\[Topologyld]\resources。 

口 _pidDir 为 该 Worker 进 程 所 对 应 的 目录 ， 所 有 由 该 Worker 产 生 的 子 进程 都 会 在 该 目录 下 写 下 
进程 编号 , 竺 到 Worker 结 束 时 就 将 杀 掉 对 应 的 子 进程 。 这 个 目录 为 $SStormDataNworkers\uuid 
pids\， 其 中 $StormData 由 配置 项 决定 ， 而 [uuid] 为 一 个 随机 的 GUID 值 ， 代 表 了 Worker 的 人 D。 

口 userResources 为 Executor 的 共享 资源 ， 目 前 没有 用 到 。 

Q _defaultResources 为 默认 资源 ， 目 前 含有 一 个 线程 池 。mk-default-Tresources 函 数 为 

Worker 创 建 了 一 个 大 小 为 TOPOLOGY-WORKER-SHARED-THREAD-POOL-SIZE 的 线程 池 , 并 

放置 于 _defaultResources 中 ， 其 键 为 executor。mk-default-resources 的 代码 如 下 : 


(defn- mk-default-resources [worker] 
(let [conf (:conf worker) 
thread-pool-size (int (conf TOPOLOGY-WORKER-SHARED-THREAD-POOL-SIZE))] 
{WorkerTopologyContext/SHARED EXECUTOR (Executors/newFixedThreadPool thread-pool-size)} 
)) 


用 户 可 以 调用 getSharedExecutor 来 获得 该 线程 池 并 使 用 它 。 


public ExecutorService getSharedExecutor() { 
return (ExecutorService) defaultResources.get(SHARED EXECUTOR); 
} 


11.1.4 TopologyContext 


在 创建 一 个 Task 时 ， 需 要 为 其 先 创建 一 个 TopologyContext 对 象 ， 以 便 可 以 更 加 容易 地 获得 
Topology 信 息 ， 例 如 系统 中 的 组 件 、 组 件 对 应 的 Task 等 。mk-topology-context-builder 函 数 用 来 
创建 该 对 象 ， 其 代码 如 下 : 


1 (defn mk-topology-context-builder [worker executor-data topology] 
2 (let [conf (:conf worker)] 

3 #(TopologyContext. 

4 topology 

5 (:storm-conf worker) 

6 (:task->component worker) 

7 (:component->sorted-tasks worker) 

8 (:component-»stream-»fields worker) 

9 (:storm-id worker) 

10 (supervisor-storm-resources-path 

11 (supervisor-stormdist-root conf (:storm-id worker))) 
12 (worker-pids-root conf (:worker-id worker)) 

13 (int %) 

14 (:port worker) 


15 (:task-ids worker) 
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16 (:default-shared-resources worker) 

17 (:user-shared-resources worker) 

18 (:shared-executor-data executor-data) 

19 (:interval-»task-»metric-registry executor-data) 
20 (:open-or-prepare-was-called? executor-data)))) 


该 函数 较为 直观 ,其 中 第 13 行 将 传人 的 参数 转换 成 为 int 类 型 ，% 表 示 占 位 符 , 传人 的 参数 为 
该 Task 的 TaskId。 


11.2 创建 Task 数据 


mk-task-data 函 数 用 来 创建 与 Task 相 关 的 数据 ， 其 参数 为 Executor 的 数据 executor-data 以 及 
该 Task 的 TaskId， 其 代码 如 下 : 


1 (defn mk-task-data [executor-data task-id] 

2 (xecursive-map 

3 :executor-data executor-data 

4 :task-id task-id 

5 :system-context (system-topology-context (:worker executor-data) executor-data task-id) 
6 

7 

8 

9 


:user-context (user-topology-context (:worker executor-data) executor-data task-id) 
:builtin-metrics (builtin-metrics/make-data (:type executor-data)) 
:tasks-fn (mk-tasks-fn «») 
object (get-task-object (.getRawTopology ^TopologyContext (:system-context <>)) 
(:component-id executor-data)))) 


口 :executor-data 为 Task 所 在 的 Executor 的 数据 。 
口 :task-id 为 该 Task 的 序号 ， 在 整个 Topology 中 是 唯一 的 。 
口 :system-context 通 过 调用 system-topology-context 方 法 获得 。 该 方法 会 调用 mk-topology- 


context-builder 函 数 创 建 TopologyContext 对 象 ， 其 传人 的 Topology 对 象 是 Worker 通 过 
system-topology 函 数 产 生 的 。system-topology 函 数 的 功能 为 在 用 户 定义 的 Topology 的 基 
础 上 添加 系统 组 件 ( 如 Acker Bolt 等 )。 

口 :user-context 的 产生 方法 与 : system-context 类 似 ， 只 不 过 它 是 通过 传人 Worker 的 :topology 

对 象 来 构建 TopologyContext 的 ， 因 此 只 包含 用 户 定义 的 Topology。 

口 :builtin-metrics 使 用 builtin-metrics/make-data 并 根据 Executor 的 类 型 来 创建 内 置 的 统 

计 信 息 如 消息 发 送 数 目 等 。 

O :tasks-fn 是 Task 的 核心 数据 成 员 ， 它 通过 mk-tasks-fn 函 数 产 生 ， 主 要 用 来 选择 消息 的 目 

标 节 点 以 及 发 送 消息 。 

O :object 对 应 于 该 Task 所 执行 的 Spout 或 Bolt 对 象 。 这 里 首先 调用 system-context 的 
getRawTopology 获 取 用 户 定义 的 Topology， 即 user-context 中 的 Topology 对 象 ， 之 后 调用 
get-task-object 方 法 ， 根 据 组 件 ID 获取 该 组 件 所 对 应 的 Spout 或 Bolt 对 象 。 
get-task-object 函 数 用 于 获取 Task 所 对 应 的 Spout 或 Bolt 对 象 ， 其 代码 如 下 : 
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1 (defn- get-task-object [^TopologyContext topology component-id] 

2 (let [spouts (.get spouts topology) 

3 bolts (.get bolts topology) 

4 state-spouts (.get state spouts topology) 

5 obj (Utils/getSetComponentObject 

6 (cond 

7 (contains? spouts component-id) (.get spout object ^SpoutSpec (get spouts 

component -id)) 
8 (contains? bolts component-id) (.get bolt object ^Bolt (get 
bolts component-id)) 

9 (contains? state-spouts component-id) (.get state spout object 
^StateSpoutSpec 
(get state-spouts component-id)) 

10 true (throw-runtime "Could not find " component-id " in " topology))) 

11 obj (if (instance? ShellComponent obj) 

12 (if (contains? spouts component-id) 

13 (ShellSpout. obj) 

14 (ShellBolt. obj)) 

15 obj ) 

16 obj (if (instance? JavaObject obj) 

17 (thrift/instantiate-java-object obj) 

18 obj )] 

19 obj 

20 )) 


21 public static Object getSetComponentObject(ComponentObject obj) { 
22 if(obj.getSetField()--ComponentObject. Fields.SERIALIZED JAVA) ( 


23 return Utils.deserialize(obj.get serialized java()); 

24 } else if(obj.getSetField()--ComponentObject. Fields.JAVA OBJECT) ( 

25 return obj.get java object(); 

26 ) else { 

27 return obj.get shell(); 

28 } 

29 } 

a 第 2~4 行 获得 所 有 用 户 定义 的 spouts、bolts 和 state-spouts 对 象 ， 每 个 组 件 只 会 属于 其 中 
一 个 集合 。 


O 第 S$~10 行 获取 对 应 的 Componentobject 类 型 ， 并 调用 getSetComponent0bject 方 法 将 其 转化 

为 实际 对 象 。 

a 第 11~15 行 进行 判断 , 若 obj 为 ShellComponent , 则 调用 shellSpout 或 者 shellBolt 进 行 封装 ， 
传人 的 obj 实 际 上 为 shellspout 或 者 ShellBolt 要 启动 的 命令 。 在 Storm 中 ， 我们 利用 
ShellSpout 以 及 shellBolt 来 完成 多 语言 处 理 ， 它 们 内 部 含有 需要 执行 的 命令 。 

O 第 16~18 行 首先 进行 判断 , 若 obj 为 ]ava0bject 对 象 , 并 且 该 对 象 含 有 full_class_name 以 及 

args_1ist 成 员 变 量 , 则 利用 instantiate-java-object 函 数 来 创建 JavaObject 所 代表 的 目标 

对 象 。instantiate-java-object 函 数 的 定义 如 下 ; 


(defn instantiate-java-object [^JavaObject obj] 
(let [name (symbol (.get full class name obj)) 
args (map (memfn getFieldValue) (.get args list obj))] 
(eval "(new "name ~@args)) 


)) 


204 


第 11 Task 


11.3 mk-tasks-fn 国 数 


mk-tasks-fn eK ory ik IRI —- PRXCtasks-fn, tasks-fnbeRZic n] He pee 3 D TREES DERBI ELI s 
收 端 TaskId 集 合 。 为 了 便于 讨论 , 这 里 将 用 于 运行 统计 的 代码 去 掉 , 详情 可 参见 第 13 章 和 第 14 章 。 
mk-tasks-fn 函 数 的 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 


(defn mk-tasks-fn [task-data] 
(let [task-id (:task-id task-data) 


executor-data (:executor-data task-data) 

component-id (:component-id executor-data) 

^WorkerTopologyContext worker-context (:worker-context executor-data) 
storm-conf (:storm-conf executor-data) 

emit-sampler (mk-stats-sampler storm-conf) 

stream-»component-»grouper (:stream-»component-»grouper executor-data) 
user-context (:user-context task-data) 

executor-stats (:stats executor-data) 

debug? (= true (storm-conf TOPOLOGY-DEBUG) ) ] 


(fn ([^Integer out-task-id “String stream “List values] 
(when debug? 
(log-message "Emitting direct: " out-task-id "; " component-id " " stream 
values)) 
(let [target-component (.getComponentId worker-context out-task-id) 
component-»grouping (get stream-»component-»grouper stream) 
grouping (get component-»grouping target-component) 
out-task-id (if grouping out-task-id)] 
(when (and (not-nil? grouping) (not- :direct grouping)) 
(throw (IllegalArgumentException. "Cannot emitDirect to a task expecting a 
regulargrouping"))) 
(if out-task-id [out-task-id]) 
)) 
([^String stream ^List values] 
(when debug? 
(log-message "Emitting: 
(let [out-tasks (ArrayList.)] 
(fast-map-iter [[out-component grouper] (get stream->component->grouper stream)] 
(when (= :direct grouper) 
;; TODO: this is wrong, need to check how the stream was declared 
(throw (IllegalArgumentException. "Cannot do regular emit to direct 
stream"))) 
(let [comp-tasks (grouper task-id values)] 
(if (or (sequential? comp-tasks) (instance? Collection comp-tasks) ) 
(.addAll out-tasks comp-tasks) 
(.add out-tasks comp-tasks) 


"on 


" "on 


component-id " " stream values)) 


out-tasks))) 


O 第 8 行 定义 的 stream->component->grouper 变 量 十 分 重要 , 它 指 定 了 系统 中 的 组 件 将 以 分 组 
函数 定义 的 方式 去 收听 流 。 

a 第 13~23 行 定义 函数 的 第 一 个 重 载 。 该 重 载 函 数 用 于 应 对 向 直接 流 发 送 消 息 的 情况 ,传人 
的 参数 中 out -task-id 为 接收 端的 TaskId，stream 为 消息 发 送 流 ，values 为 要 发 送 的 消息 。 
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当 用 户 将 TOPOLOGY_DEBUG 设 置 为 true 时 ，debug? 方 法 也 将 返回 true， 此 时 系统 将 对 输入 的 
消息 进行 记录 。 

口 第 16~19 行 通过 out-task-id 获 得 其 所 在 的 组 件 以 及 该 组 件 对 该 直接 流 的 收听 方式 。 直接 流 
只 能 采取 直接 分 组 的 方式 进行 收听 ， 第 20~23 行 对 此 进行 检测 。 注 意 若 out-task-id 为 空 ， 
则 表示 该 流 没 有 组 件 收听 ， 这 在 Storm 中 是 允许 的 ， 该 消息 将 被 丢弃 掉 。 由 于 发 送 到 直接 
流 的 消息 的 目标 Task 已 经 确定 ， 因 此 这 部 分 重 载 的 最 主要 功能 其 实 是 完成 异常 检测 。 

O 第 24~38 行 定义 函数 的 另外 一 个 重 载 ， 其 输入 参数 仅 包括 消 息 所 在 的 流 以 及 消息 本 身 。 第 
28 行 根据 流 找到 所 有 收听 该 流 的 组 件 及 其 收听 方式 。 类 似 地 ， 对 于 非 直接 流 ， 不 能 使 用 
直接 分 组 的 方式 进行 收听 。 

a 第 32 行 调用 grouper 函 数 来 获得 目标 节点 的 TaskId, 输入 为 发 送 消息 的 Task 对 应 的 TaskId 以 

及 消息 本 身 。 例 如 ， 随 机 分 组 的 分 组 函数 会 根据 消息 的 哈 希 值 来 选择 目标 TaskId。 

口 第 33~36 行 会 根据 分 组 函数 返回 的 是 集合 还 是 单个 元 素 而 调用 不 同 的 函数 将 结果 添加 到 

ret 中 。 

O 第 37 行 返回 目标 TaskId 的 集合 ， 消 息 将 被 发 送 到 这 些 Task。 


11.4 send-unanchored 


Task 使 用 send-unanchored 函 数 来 发 送 消息 。 该 函数 会 利用 tasks-fn 函 数 来 获得 目标 节点 的 
TaskId, 然后 调用 Execturor 的 :transfer-fn 国 数 将 消息 发 送 到 发 送 队 列 中 , 最 终 Worker 会 利用 ZMQ 
将 消息 发 送 给 目标 Task。 和 若 目 标 Task 与 当前 Task 在 同一 个 Worker 中 ，Worker 则 会 将 消息 直接 发 送 
到 该 Task 的 接收 队列 中 。send-unanchored 的 代码 如 下 : 


1 (defn send-unanchored 

2 ([task-data stream values overflow-buffer] 

3 (let [^TopologyContext topology-context (:system-context task-data) 
4 tasks-fn (:tasks-fn task-data) 

5 transfer-fn (-» task-data :executor-data :transfer-fn) 
6 out-tuple (TupleImpl. topology-context 

7 values 

8 (.getThisTaskId topology-context) 

9 stream)] 

10 (fast-list-iter [t (tasks-fn stream values)] 

11 (transfer-fn t 

12 out-tuple 

13 overflow-buffer) 

14 

15 ([task-data stream values] 

16 (send-unanchored task-data stream values nil) 

17 ) 


O 第 15~17 行 是 函数 的 一 个 重 载 ， 为 含有 3 个 形 参 的 实现 。 它 将 调用 基于 4 个 参数 的 重 载 ， 第 
4 个 参数 表示 是 否 要 将 发 送 的 消息 放 于 一 个 缓存 里 面 。 对 于 Ack 或 Fail 消 息 , 系统 需要 尽快 
地 将 其 发 送出 去 ， 因 此 调用 的 都 是 非 缓 存 的 重 载 方法 。 
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a 第 2~14 行 定义 了 方法 的 另 一 个 重 载 。 


11.5 


第 6~9 行 构建 一 个 要 发 送 的 消息 ， 第 10 行 通过 调用 


tasks-fn 函 数 计算 得 到 该 消息 的 目标 TaskId, 第 11~14 行 则 调用 Executor 对 应 的 transfer-fn 


函数 将 消息 发 送出 去 。 


创建 Task 


mk-task 函 数 用 于 创建 一 个 新 的 Task， 其 主要 目标 为 通过 调用 mk-task-data 函 数 为 该 Task 创 建 

应 的 数据 。 该 遇 数 将 用 户 定 义 的 钧 子 晒 数 注册 到 :user-context 数 据 中 , 同时 各 系统 组 件 发 送 一 

目前 ， 和 RD 不 过 目前 Storm 中 并 没有 使 用 SystemBolt， 
要 用 来 统计 Worker 的 运行 情况 。mk-task 的 代码 如 下 所 示 : 


(defn mk-task [executor-data task-id] 


11.6 


(let [task-data (mk-task-data executor-data task-id) 
storm-conf (:storm-conf executor-data)] 
(doseq [klass (storm-conf TOPOLOGY-AUTO-TASK-HOOKS)] 
(.addTaskHook ^TopologyContext (:user-context task-data) (-» klass 
Class/forName .newInstance))) 


SystemBolt 主 


;; when this is called, the threads for the executor haven't been started yet, 
33 So we won't be risking trampling on the single-threaded claim strategy disruptor queue 


(send-unanchored task-data SYSTEM-STREAM-ID ["startup"]) 
task-data 


)) 


Storm 中 传输 的 消息 以 及 序列 化 


本 节 将 介绍 Storm 是 如 何 对 消息 进行 序列 化 的 ， 并 分 析 实 际 的 传输 内 容 。 
KryoTupleSerializer 类 用 于 实现 对 消息 的 序列 化 ， 其 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 
9 


public class KryoTupleSerializer implements ITupleSerializer { 
KryoValuesSerializer kryo; 
SerializationFactory.IdDictionary ids; 
Output kryoOut; 


public KryoTupleSerializer(final Map conf, final GeneralTopologyContext context) { 


_kryo = new KryoValuesSerializer(conf); 
_kryoOut = new Output(2000, 2000000000); 
_ids = new SerializationFactory.IdDictionary(context.getRawTopology()); 


} 


public byte[] serialize(Tuple tuple) { 
try { 


_kryoOut.clear(); 

_kryoOut .writeInt(tuple.getSourceTask(), true); 

_kryoOut .writeInt(_ids.getStreamId(tuple.getSourceComponent() , 
tuple.getSourceStreamId()), true); 

tuple.getMessageId().serialize( kryoOut); 
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19 _kryo.serializeInto(tuple.getValues(),  kryoOut); 
20 return kryoOut.toBytes(); 

21 } catch (IOException e) { 

22 throw new RuntimeException(e); 

23 } 

24 } 

25 } 


从 第 16~19 行 代码 可 以 看 出 ，Storm 实 际 传输 的 消息 为 : 
SourceTaskId:int; StreamId:int; messageId:MessageId;TupleValues: List<Object> 


其 中 ， 流 序号 是 对 组 件 中 所 有 的 流 排序 后 确定 的 统一 编号 ，IdDictionary 类 会 根据 输入 的 
Topology 定 义 获取 所 有 的 组 件 名 字 以 及 它们 的 流 序号 , 然后 进行 编号 。TupleValues 为 用 户 实际 发 
送 的 消息 。 

MessageId 类 存储 从 消息 的 RootId 到 其 衍生 消息 的 消息 ID 的 异 或 值 的 映射 关系 , 它 用 于 跟踪 消 
E. ANTI K. 

MessageId 类 中 用 于 实现 序列 化 的 方法 如 下 : 

public void serialize(Output out) throws IOException { 
out.writeInt( anchorsToIds.size(), true); 


1 

2 

3 for(Entry«Long, Long» anchorToId:  anchorsToIds.entrySet()) { 
4 out .writeLong(anchorToId.getKey()); 
5 

6 

7 


out .writeLong(anchorToId.getValue()); 


) 


序列 化 的 数据 为 < 元 素 个 数 ，[RootId，AckVal]+>， 而 反 序列 化 方法 与 其 类 似 。 
KryoTupleDeserializer 类 用 来 对 收 到 的 消息 字 节 数组 进行 反 序列 化 ， 相 关 代码 如 下 : 


public Tuple deserialize(byte[] ser) { 
try ( 
_kryoInput.setBuffer(ser) ; 
int taskId = kryoInput.readInt(true); 
int streamId = kryoInput.readInt(true); 
String componentName = _context.getComponentId(taskId) ; 
String streamName = _ids.getStreamName(componentName, streamId) ; 
MessageId id = MessageId.deserialize( kryoInput); 
List<Object> values = _kryo.deserializeFrom(_kryoInput) ; 
return new TupleImpl( context, values, taskId, streamName, id); 
jcatch(IOException e) { 
throw new RuntimeException(e); 
) 


} 

反 序 列 化 的 过 程 是 : 首先 依次 读 取 TaskId， 并 通过 读 取 的 流 序号 查找 映射 表 获 取 流 名 称 ， 接 
下 来 调用 MessageId 反 序列 化 方法 读 取 MessageId 信 息 ， 然 后 读 取 用 户 发 送 的 消息 ， 最 后 构建 
TupleImp1 对 象 并 返回 。 注 意 这 里 的 流 序号 只 用 于 消息 的 传输 ， 其 他 地 方 看 到 的 流 序号 实际 上 对 
应 于 这 里 的 流 名 称 。 


Storm 的 Ack 框 架 


在 Storm 中 ， 如 何 表 示 一 条 消息 是 否 已 被 成 功 处 理 了 呢 ? Storm 采 用 创新 的 Ack 框 架 (详情 可 
参照 http:/github.com/nathanmarz/storm/wiki/Guaranteeing-message-processing ) 对 Topology 中 的 消 
息 进 行 跟踪 。 

Storm 利 用 Acker Bolt 节 点 跟踪 消息 。 当 S$Spout 发 送出 去 的 消息 以 及 这 些 消息 所 衍生 出 来 的 消 
息 均 被 成 功 处 理 后 ，Spout 将 收 到 对 应 于 该 消息 的 Ack。Ack 框 架 的 实现 要 点 如 下 。 

口 Storm 中 每 条 发 送出 去 的 消息 都 会 对 应 一 个 随机 的 消息 ID。 

O Spout 发 送 消 息 后 , 将 向 Acker Bolt 发 送 一 条 消息 , 该 消息 的 内 容 为 <RootId, 消 息 ID>, Acker 

Bolt 将 为 该 消息 创建 一 条 跟踪 项 。 

O Bolt 产 生 要 发 送 的 消息 时 ， 会 计算 每 条 新 消息 的 消息 ID ， 并 将 消息 ID 发 送 至 Acker Bolt, 

Acker Bolt 对 消息 ID 进行 异 或 后 存储 。 于 是 ，Storm 对 新 发 送 的 消息 进行 了 跟踪 。 

口 Bolt 对 输入 的 消息 进行 Ack 时 ， 也 会 将 该 消息 ID 发 送 到 Acker Bolt, Acker Bolt 对 消息 ID 进 
行 异 或 后 存储 。 由 于 该 消息 在 被 发 送 时 ， 已 经 向 Acker Bolt 发 送 过 消息 ID ， 之 后 在 被 Ack 
时 又 再 次 发 送 该 消息 ID。 根 据 异 或 的 语义 ， 这 相当 于 对 该 消息 的 跟踪 结 

O Acker Bolt 在 更 新 某 一 个 消息 的 跟踪 值 时 , 知 发 现 其 跟踪 值 变 为 零 , 则 向 Spout 节 点 发 送 消 

息 ， 表 明 Spout 发 送 的 这 条 消息 已 经 被 成 功 处 理 。 

口 所 有 消息 的 消息 ID 都 将 更 新 至 根 消 息 上 ， 根 消息 为 Spout 发 送出 去 的 消息 ，Bolt 新 产生 的 

消息 并 不 会 被 单独 跟踪 。 

O 若 Spout 在 发 送 消息 时 未 指定 用 于 消息 跟踪 的 ID ， 系 统 则 不 对 消息 进行 跟踪 。 若 系统 中 不 

含有 Acker Bolt， 消 息 也 不 会 被 跟踪 。 

O Spout 的 每 条 消息 以 及 由 该 消息 演化 出 来 的 所 有 消息 的 跟踪 负载 为 16 个 字 节 , 8 个 字 节 的 根 
消息 ID 以 及 8 个 字 节 的 消息 跟踪 值 Ackvalue。 但 是 , 由 于 Storm 中 采用 HashMap 对 其 进行 存 
储 ， 在 32 位 的 JVM 中 ， 每 条 消息 至 少 需要 20 个 字 节 的 额外 负载 ， 故 一 条 消息 的 跟踪 需要 
40 个 字 节 左右 的 负载 。 许 多 文档 认为 只 需要 20 个 字 节 是 不 正确 的 。 读 者 可 以 参考 JDK 中 有 
关 HashMap 实 现 的 内 容 来 分 析 哈 硕 表 中 每 一 条 消息 需要 的 负载 。 
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12.1 Acker Bolt 的 实现 分 析 


AckerBolt 属 于 系统 级 的 组 件 , 它们 由 系统 创建 ， 主 要 用 来 跟踪 消息 以 及 该 消息 衍生 出 来 的 消 
息 是 否 被 完全 处 理 。 

一 条 消息 从 Spout 产 生 之 后 , 经 过 若干 处 理 节 点 , 可 能 会 衍生 出 很 多 消息 , 而 这 些 消息 以 Spout 
发 送 的 消息 为 根 ， 这 就 构成 一 张 图 结构 。 在 Storm 中 ， 只 有 当 所 有 衍生 出 来 的 消息 都 被 成 功 处 理 
后 ， 这 条 从 Spout 发 送出 来 的 消息 才 被 认为 是 成 功 处 理 的 。Storm 中 的 Acker Bolt 就 是 用 来 跟踪 消 
息 的 系统 节点 。 当 一 个 Bolt 同 时 从 两 种 类 型 的 Spout 接 收 消息 时 , 其 产生 的 消息 的 根 为 这 两 个 Spout 
发 送 的 消息 ，12.3 节 会 对 这 种 情况 进行 讨论 。 

mk-acker-bolt 也 数 用 来 定义 一 个 Acker-bolt， 该 Bolt 实 例 化 自 IBolt 接 口 ， 其 代码 如 下 : 


1 (defn mk-acker-bolt [] 

2 (let [output-collector (MutableObject.) 

3 pending (MutableObject.)] 

4 (Teify IBolt 

5 (^void prepare [this ^Map storm-conf ^TopologyContext context ^OutputCollector collector] 
6 (.setObject output-collector collector) 

7 (.setObject pending (RotatingMap. 2)) 

8 

9 

1 


(^void execute [this ^Tuple tuple] 


0 (let [^RotatingMap pending (.getObject pending) 

11 stream-id (.getSourceStreamId tuple)] 

12 (if (= stream-id Constants/SYSTEM TICK STREAM ID) 

13 (.rotate pending) 

14 (let [id (.getValue tuple 0) 

15 ^OutputCollector output-collector (.getObject 
output-collector) 

16 curr (.get pending id) 

17 curr (condp = stream-id 

18 ACKER-INIT-STREAM-ID (-> curr 

19 (update-ack (.getValue 

tuple 1)) 
20 (assoc :spout-task (.getValue 
tuple 2))) 
21 ACKER-ACK-STREAM-ID (update-ack curr (.getValue 
tuple 1)) 

22 ACKER-FAIL-STREAM-ID (assoc curr :failed true))] 

23 (.put pending id curr) 

24 (when (and curr (:spout-task curr)) 

25 (cond (= 0 (:val curr)) 

26 (do 

27 (.remove pending id) 

28 (acker-emit-direct output-collector 

29 (:spout-task curr) 

30 ACKER-ACK - STREAM- ID 

31 [id] 

32 )) 

33 (:failed curr) 

34 (do 


35 (.remove pending id) 
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36 (acker-emit-direct output-collector 
37 (:spout-task curr) 
38 ACKER-FAIL-STREAM-ID 
39 [id] 

40 )) 

41 

42 (.ack output-collector tuple) 

43 )))) 

44 (void cleanup [this] 

45 ) 

46 ))) 


O 第 2~3 行 定义 了 Acker Bolt 中 的 两 个 类 成 员 变 量 : output-collector 用 于 向 外 发 送 数据 ; 
pending 为 RotatingMap 类 型 , 用 来 存储 每 一 个 从 Spout 发 送出 来 的 消息 的 RootId 以 及 目前 该 
消息 的 跟踪 值 (AckValue )。Acker Bolt 就 是 通过 不 断 更 新 和 检测 跟踪 值 来 判断 该 消息 是 否 
已 经 被 完全 成 功 处 理 的 。RotatingMap 主 要 用 于 消息 的 超时 。 

O 第 5~8 行 定义 了 Acker Bolt 的 prepare 方 法 来 设置 类 的 成 员 变 量 。 这 里 设置 pending 的 桶 数目 

为 2。 

口 9~46 行 定义 Acker Bolt 的 execute 方 法 ， 其 中 Acker Bolt 的 输入 流 有 如 下 4 种 。 

(1) SYSTEM TICK STREAM ID: 系统 预定 义 流 ， 用 于 消息 超时 。 

(2) ACKER-INIT-STREAM-ID: Acker Bolt 初 始 化 流 ， 由 Spout 向 其 发 送 消息 。 

(3) ACKER-ACK-STREAM-ID: Acker Bolt 的 Ack 消 息 流 ， 由 Bolt 向 其 发 送 消息 。 

(4) ACKER-FAIL-STREAM-ID: Acker Bolt 的 Fail 消 息 流 ， 由 Bolt 向 其 发 送 消息 。 

Acker Bolt 首 先 检测 输入 消息 的 来 源流 , 然后 根据 流 的 类 型 进行 下 列 操作 。 

m SYSTEM TICK STREAM ID: 这 种 情况 下 ，Acker Bolt 会 对 成 员 变 量 pending 进 行 旋转 操作 ， 
然后 退出 execute 方 法 ,该 操作 将 pending 中 最 早 的 一 个 桶 中 的 数据 删除 掉 ， 于 是 实现 了 
消息 的 超时 。 由 于 初始 化 RotatingMap 时 ,未 传人 关于 expire 的 回调 方法 ， 故 该 操作 只 是 
进行 简单 的 删除 。 如 果 继 续 对 已 经 删除 掉 的 消息 的 RootId 进 行 Ack 操 作 ， 就 会 创建 新 的 
<RootId, 跟 踪 值 对， 但 是 由 于 数据 已 被 删除 过 的 原因 ， 跟 踪 值 基本 上 不 会 再 回 到 零 ， 

所 以 Spout 将 永远 也 收 不 到 它 发 送出 去 的 这 条 消息 的 Ack。Spout 会 通过 自 有 的 超时 机 制 ， 

将 这 条 消息 标记 为 处 理 失 败 ， 然 后 调用 Spout 的 失败 函数 来 决定 对 失败 消息 进行 重 传 还 

是 忽略 。 这 个 操作 的 结果 是 去 除 处 于 僵 死 状态 的 消息 跟踪 。 例 如 ，Spout 发 送出 去 一 条 

消息 A， 它 需要 经 过 BoltA 和 BoltB ， 然 而 Bolt B 在 处 理 过 程 中 由 于 机 器 故障 死 掉 了 ， 那 

么 消息 A 对 应 的 xcRootId,AckValue> 在 Acker Bolt 中 就 处 于 僵 死 状态 。 

ACKER-INIT-STREAM-ID: 此 时 输入 消息 的 模式 为 <RootId,RawAckValue, SpoutTaskId>。Acker 

Bolt 会 根据 RootId 取 出 <RootId，AckValue> ， 如 果 不 存在 Roottd ， 那 么 Ackvalue 将 是 

RawAckValue。 在 第 18~20 行 中 ，Acker Bolt 根 据 输 入 消息 的 AckValue 对 pending 中 AckValue 

进行 更 新 , 同时 将 Spout 的 TaskId 作 为 关键 字 存 储 在 curr 对 象 中 ( 利用 Clojure 的 assoc 方 法 )。 

ACKER-ACK-STREAM-ID: 输入 消息 的 模式 为 <RootId,AckValue>， 与 原 有 AckValue 进 行 异 

或 操作 并 存储 。 


1 
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m ACKER-FAIL-STREAM-ID: 输入 消息 的 模式 为 RootId>。 设 置 failed 为 true， 表 示 消 息 的 


处 理 已 经 失败 。 
O 在 第 25~32 行 中 ， 若 此 时 消息 对 应 的 跟踪 值 已 经 为 零 


<RootId>。 


消息 ， 模 式 为 <cRootId>。 


的 消息 都 是 没有 进行 跟踪 的 。 


12.2 ”启动 消息 跟踪 


， 那 么 Storm 认 为 该 消息 以 及 所 有 衍 
生 的 消息 都 已 被 成 功 处 理 ， 这 时 会 通过 向 ACK- STREAM 流 向 Spout 节 点 发 送 消息 E. 模式 为 


O 在 第 36~41 行 中 ， 若 此 时 消息 被 标记 为 失败 ， 那 么 Storm 会 通过 FAIL-STREAM 流 问 Spout 发 送 


a 第 42 行 对 输入 的 消息 进行 Ack 操 作 。 实 际 上 这 行 代码 并 没有 实际 的 作用 ， 因 为 Acker 收 到 


在 Spout 癌 外 发 送 消息 时 ，Storm 根 据 系统 中 是 否 存在 Acker Bolt 以 及 发 送 的 消息 是 否 带 有 消 


HJF (MessageId) 来 决定 是 否 对 消息 进行 跟踪 。 
消息 。Spout 使 用 send-spout-msg 函 数 来 向 外 发 送 消息 。 
其 中 与 消息 跟踪 相关 的 部 分 ， 其 代码 如 下 : 


被 跟踪 
函数 在 第 


，Acker Bolt 将 收 到 一 条 初始 化 
名 10 章 中 讨论 过 ， 本 节 主 要 关心 


1 send-spout-msg (fn [out-stream-id values message-id out-task-id] 

2 (.increment emitted-count) 

3 (let [out-tasks (if out-task-id 

4 (tasks-fn out-task-id out-stream-id values) 

5 (tasks-fn out-stream-id values)) 

6 rooted? (and message-id has-ackers?) 

7 root-id (if rooted? (MessageId/generateId rand)) 

8 out-ids (fast-list-for [t out-tasks] (if rooted? (MessageId/generateId rand)))] 
9 (fast-list-iter [out-task out-tasks id out-ids] 

10 (let [tuple-id (if rooted? 

11 (MessageId/makeRootId root-id id) 

12 (MessageId/makeUnanchored)) 

13 out-tuple (TupleImpl. worker-context 

14 values 

15 task-id 

16 out-stream-id 

17 tuple-id)] 

18 (transfer-fn out-task 

19 out-tuple 

20 overflow-buffer) 

21 

22 (if rooted? 

23 (do 

24 (.put pending root-id [task-id 

25 message-id 

26 {:stream out-stream-id :values values} 
27 (if (sampler) (System/currentTimeMillis))]) 
28 (task/send-unanchored task-data 


29 ACKER-INIT-STREAM-ID 
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30 [root-id (bit-xor-vals out-ids) task-id] 

31 overflow-buffer)) 

32 (when message-id 

33 (ack-spout-msg executor-data task-data message-id 
34 {:stream out-stream-id :values values} 

35 (if (sampler) 0)))) 

36 (or out-tasks []) 

37 ) 


a 第 3~8 行 用 于 计算 得 到 该 消息 的 接收 端 Task 集 合 。 若 系统 中 含有 Acker Bolt, Jf-HSpoutfE 
发 送 消息 时 指定 了 MessageId，Storm 将 对 这 条 消息 进行 跟踪 ， 并 为 其 生成 一 条 RootId， 然 
后 为 发 送 到 每 一 个 Task 上 面 的 消息 也 生成 一 个 消息 ID 。 消 息 ID 是 通过 调用 MessageId 的 
generateId 方 法 来 产生 的 ， 为 一 个 长 整 型 随机 数 。 

口 第 10~21 行 为 每 一 个 接收 端 Task 构 建 一 条 消息 并 将 其 发 送出 去 。 第 10~12 行 会 创建 tuple-id 
对 象 ， 它 是 一 个 哈 希 表 ,， 用 来 表示 产生 该 消息 的 最 初 父 节点 以 及 对 应 的 Ack 值 。 例 如 ,一 
个 用 于 连接 两 个 流 的 Bolt 节 点 会 根据 输入 的 两 条 消息 产生 一 条 消息 , 而 产生 出 来 的 消息 所 
对 应 的 tuple-id 域 会 含有 两 条 记录 , 分 别 为 每 个 流 的 消息 源 消息 的 RootId 以 及 目前 的 跟踪 
值 。 对 于 Spout 来 讲 ，RootId 即 为 第 7 行 创 建 的 随机 数 。 若 不 进行 消息 跟踪 ，tuple-id 则 对 
应 一 个 空 的 哈 希 表 。 

O 第 24~27 行 将 <RootId, 元 数据 > 存储 在 RotatingMap 中 。 消 息 元 数据 中 含有 Spout 的 TaskId、 
MessageId 、StreamId 以 及 消息 的 内 容 。 存 储 原始 的 消息 内 容 可 以 方便 以 后 的 失败 重 传 ， 
不 过 目前 Storm 中 并 没有 利用 已 经 存储 的 消息 内 容 , 而 是 希望 用 户 可 以 通过 MessageId 来 自 
己 维 护 已 经 发 送出 去 的 消息 。 当 Ack 框 架 判 定 消息 处 理 失 败 时 ， 将 调用 Spout 的 Fail 方 法 ， 
但 Spout 的 fail 方 法 的 原型 如 下 所 示 , 其 参数 仅仅 含有 msgId, storm 未 将 消息 内 容 传 回 给 fail 
方法 ， 或 用 户 无 法 得 到 storm 缓 存 的 消息 。 由 于 Spout 发 送出 去 的 消息 是 在 内 存 中 的 ， 它 没 
办 法 保证 Spout 重 启 并 且 消 息 处 理 失 败 后 ， 是 否 还 可 以 将 原始 消息 返回 给 用 户 的 回调 函数 : 


void fail(Object msgId); 


O 第 28~31 行 向 ACKER-INIT-STREAM 发 送 一 条 消息 ,该 消息 为 <cRootId, T1^T2^.^Tn, Spout-Task-Id>, 
即 输入 消息 RootId 为 键 , 发 送 到 每 一 个 Task 上 面 的 消息 的 消息 也 的 异 或 值 作为 初始 化 的 跟 
踪 值 ， 同 时 需要 传人 该 Spout 的 Taskld。 当 Spout 收 到 针对 某 条 消息 的 Ack 或 Fail 时 ， 可 以 用 
该 值 来 验证 这 条 消息 是 不 是 由 该 Spout 发 送出 去 的 。 

a 第 32~35 行 是 针对 Spout 发 送 消息 时 带 有 Messageld 但 系统 中 并 没有 Acker Bolt 情 况 的 一 种 
特殊 处 理 。 此 时 ，Storm 将 直接 调用 Spout 的 Ack 方 法 ， 系 统 不 对 消息 进行 跟踪 。 


12.3 ”消息 跟踪 


Bolt 在 发 送 消息 时 ， 系 统 需要 继续 对 其 进行 跟踪 ， 这 些 由 Bolt 新 发 送 的 消息 对 应 于 从 Spout 收 
到 消息 的 衍生 消息 。Bolt 使 用 bolt-emit 函 数 来 发 送 消 息 , 本 节 主 要 讨论 其 中 与 消息 跟踪 相关 的 部 
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分 ， 相 关 代码 如 下 : 


1 bolt-emit (fn [stream anchors values task] 

2 (let [out-tasks (if task 

3 (tasks-fn task stream values) 

4 (tasks-fn stream values))] 

5 (fast-list-iter [t out-tasks] 

6 (let [anchors-to-ids (HashMap.)] 

7 (fast-list-iter [^TupleImpl a anchors] 

8 (let [root-ids (-» a .getMessageId .getAnchorsToIds .keySet)] 


9 (when (pos? (count root-ids)) 

10 (let [edge-id (MessageId/generateId rand)] 
11 (.updateAckVal a edge-id) 

12 (fast-list-iter [root-id root-ids] 

13 (put-xor! anchors-to-ids root-id edge-id)) 
14 0) 

15 (transfer-fn t 

16 (TupleImpl. worker-context 

17 values 

18 task-id 

19 stream 

20 (MessageId/makeId anchors-to-ids))))) 

21 (or out-tasks []))) 

22 


口 bolt-emit 函 数 的 传人 参数 为 消息 标记 (anchors ), 它 对 应 于 该 消息 的 父 节 点 消息 。 为 了 保 

证 Ack 系 统 正常 工作 ， 用 户 需 要 明确 其 产生 的 消息 是 由 哪些 消息 衍生 的 。 

a 第 6 行 创建 一 张 哈 希 表 ， 用 于 存储 本 消息 的 消息 标记 。 

口 第 8~14 行 对 标记 消息 的 跟踪 值 进行 更 新 。 为 了 减少 与 Acker Bolt 通 信 的 次 数 ， 此 处 进行 了 
优化 。 标 记 消 息 的 跟踪 值 用 来 表示 在 该 Bolt 上 由 标记 消息 所 衍生 出 来 的 消息 的 异 或 值 。 例 
如 , 输入 消息 Ti 产生 Ti 、Ts 和 T4,， 则 输入 消息 Ti 的 跟踪 值 为 TAT3^T4， 在 对 消息 Ti 进行 Ack 
操作 时 ， 发 送 给 Acker Bolt 的 值 为 RootId，T2^Ti^T4>。 

a 第 11 行 对 标记 消息 的 跟踪 值 进行 更 新 。 

a 第 12~13 行 为 新 产生 的 消息 创建 标记 ， 其 值 为 <RootId，edge-id>。 

下 面 看 一 下 在 Bolt 的 0utputCollector 中 Ack 的 方法 实现 : 


1 (^void ack [this ^Tuple tuple] 

2 (let [^TupleImpl tuple tuple 

3 ack-val (.getAckVal tuple) ] 

4 (fast-map-iter [[root id] (.. tuple getMessageId getAnchorsTolds) ] 
5 (task/send-unanchored task-data 
6 
7 
8 


ACKER-ACK-STREAM-ID 
[root (bit-xor id ack-val)]) 
) 


对 一 条 消息 进行 Ack 操 作 时 ， 需 要 对 该 消息 所 有 的 标记 消息 进行 操作 。 消 息 标记 表示 这 条 消 
息 的 父 消息 。 
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fast-map-iter 用 于 遍历 一 个 哈 希 表 。 类 似 地 ,fast-list-iter 用 于 遍历 一 个 列表 , 是 Storm 的 Clojure 
代码 中 常见 的 一 个 函数 ， 它 与 通常 的 序列 遍历 操作 是 相同 的 ， 但 理论 上 效率 更 高 。 由 于 Clojure 
中 的 序列 都 是 Lazy-Evaluation ( 数据 真正 被 用 到 时 产生 )， 为 了 提高 效率 ，fast-1list-iter 将 其 分 
成 了 多 个 部 分 来 弥补 Lazy-Evaluation 带 来 的 效率 损失 。 我 在 本 机 上 进行 了 一 些 实验 ， 发 现 
fast-list-iter 并 非 如 想象 中 那样 加 快 了 速度 。 例 如 ， 在 下 面 的 例子 中 ，doseq 函 数 的 性 能 更 好 : 


user=> (time (fast-list-iter [a (range 10000000)] ())) 
"Elapsed time: 388.642758 msecs" 

user=> (time (doseq [item (range 10000000)]())) 
"Elapsed time: 175.036754 msecs" 


Bolt 所 对 应 的 Fail 方 法 实现 起 来 较为 简单 ， 它 只 是 向 ACKER-FAIL-STREAM-ID 发 送 了 消息 的 
Rootfd4， 而 Acker Bolt 会 对 该 消息 进行 失败 处 理 ， 相 关 代 码 如 下 : 
(^void fail [this ^Tuple tuple] 
(fast-list-iter [root (.. tuple getMessageId getAnchors)] 
(task/send-unanchored task-data 


ACKER-FAIL-STREAM-ID 
[root])) 


12.4 Ack 机 制 的 例子 


图 12-1 演 示 了 Ack 框 架 是 如 何 工作 的 。 
下 面 简 要 解释 一 下 图 12-1。 


— i (8) 
M Bolt? 


© © 


Acker Bolt 


ACKER _ACK STREAM 
ACKER FAIL. STREAM 


uu I NEU 
pou cx 


图 12-1 ”Ack 框 架 的 例子 
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口 在 第 DD~@@ 步 中 ，Spout 发 送 T1 到 Bolt1， 发送 T, 到 Bolt;。T1 和 Ts 具有 相同 的 内 容 , 但 表示 不 
同 的 备份 。 每 条 消息 都 会 对 应 一 个 ID。 消息 Ti 的 anchors 为 <RootId, T>, 消息 Ts 的 anchors 
为 <RootId，T,>。 

O 在 第 @ 步 中 ，Spout 在 Acker Bolt 中 注册 了 一 条 记录 RootId=Ti^T,。 

口 在 第 @ 步 与 第 @ 步 中 ，Bolti 发 送 新 的 消息 T3>、T4、Ts 到 Bolt;， 同 时 对 输入 的 消息 进行 Ack 
操作 ， 消 息 的 内 容 为 <cRootId，Ti^T^Ts^Ts>。 此 时 ，Acker Bolt 中 的 跟踪 项 为 <cRootId， 
Ta^Ta^Ti^Ta^Ta^Ts=>Ta^Ta^Ta^Ts>。 消 息 T; 的 消息 标记 为 <cRootId，T3>。 

O 在 第 @ 步 中 ，Bolts 对 输入 的 消息 T 进 行 Ack 操 作 ， 它 没有 产生 新 消息 。 发 送 到 Acker Bolt 
的 消息 为 <RootId, Ti>， 此 时 Acker Bolt 中 的 跟踪 项 为 <RootId= TAT3AT4ATSAT2= TTT > 
Ts 异 或 后 消失 。 

a 在 第 @ 步 中 ，Bolt; 对 输入 的 消息 进行 Ack 操 作 ， 发 送 的 消息 为 <RootId，Ts^Ta^Ts>， 此 时 

Acker Bolt 中 的 跟踪 项 为 <cRootId, Ts^Ta^Ts^ T;^T,^T;=>0>0 

口 在 第 @ 步 中 ，Acker Bolt 发 现 RootId 对 应 的 值 为 零 ， 它 认为 该 RootId 对 应 的 消息 以 及 所 
有 衍生 出 来 的 消息 均 已 经 被 成 功 处 理 ， 于 是 它 向 Spout 发 送 消 息 ， 而 Spout 将 调用 Ack 回 
调 方 法 。 

注意 ， 第 @~@ 步 是 异步 执行 的 。 为 了 便于 讨论 ， 这 里 给 定 了 顺序 。 但 是 ， 通 常 对 输入 消息 

进行 Ack 操 作 是 在 该 Bolt 已 经 发 送 消 息 之 后 进行 的 。 若 不 想 继续 对 消息 进行 跟踪 ， 则 可 以 先 对 输 

人 消息 进行 Ack 操 作 ， 然 后 再 发 送 消息 。 

每 条 被 处 理 的 消息 必须 进行 Ack 或 者 Fail 操 作 否 则 ,虽然 有 超时 机 制 可 以 对 过 期 消息 进行 清 

空 ， 但 可 能 导致 消息 不 断 重 传 。 


系统 运行 统计 


对 于 运行 中 的 Topology，Storm 会 对 其 运行 状态 进行 统计 ， 并 将 统计 结果 展示 在 Storm ULE o 
例如 ， 每 个 Executor 发 送 消息 的 条 数 以 及 被 Ack/Fail 的 消息 条 数 ， 等 等 。 这 些 统计 信息 会 被 Worker 
以 心跳 的 方式 ， 通 过 ZooKeeper 这 一 中 间 媒 介 ， 最 终 传输 给 Nimbus， 并 在 Storm UI 上 展示 。 

Storm 采 用 滑动 窗口 算法 来 更 新 统计 信息 ， 该 算法 可 以 及 时 反映 系统 当前 的 运行 状态 。 我 们 
则 可 以 根据 最 近 十 分 钟 的 运行 统计 来 判断 Topology 是 否 状态 良好 。 例 如 ， 我 们 可 以 及 时 获悉 
Topology 中 是 否 不 断 有 消息 产生 这 些 消 息 是 否 已 被 处 理 等 。 为 了 降低 运行 统计 的 负载 ，Storm 会 
使 用 采样 算法 来 更 新 统计 信息 。 

本 章 将 对 Storm 中 的 运行 统计 算法 以 及 Storm 内 置 的 运行 统计 进行 详细 介绍 。 


13.1 基础 数据 结构 以 及 更 新 算法 


Storm 的 运行 统计 数据 被 分 成 了 多 种 类 别 ， 例 如 ， 每 一 个 Task 所 发 送 的 消息 数目 就 属于 其 中 
一 类 运行 统计 数据 。 对 于 每 一 个 统计 类 别 ，Storm 又 进一步 将 其 分 为 三 个 统计 时 间 区 间 ， 即 最 近 
10 分 钟 、 最 近 3 个 小 时 和 最 近 1 天 。 对 于 每 种 类 别 的 每 一 种 统计 时 间 区 间 ，Storm 都 采用 了 滑动 窗 
口算 法 来 对 其 进行 更 新 。 

例如 ， 对 于 最 近 10 分 钟 的 运行 统计 类 别 ，Storm 将 以 30 秒 为 一 个 时 间 窗 口 ， 即 10 分 钟 的 区 间 
被 分 成 了 20 个 小 的 统计 窗口 。 对 于 新 产生 的 统计 信息 , 若 当 前 时 间距 离 最 近 的 一 个 时 间 窗 口 的 创 
建 时 间 起 过 了 30 秒 钟 ， 则 创建 一 个 新 的 时 间 窗 口 ， 否 则 将 统计 信息 更 新 至 最 近 的 时 间 窗 口中 。 查 
询 运行 统计 时 , 将 返回 最 近 20 个 统计 窗口 的 运行 统计 合并 后 的 结果 , 同时 会 将 过 期 的 时 间 窗 口 删 
除 ， 这 样 就 实现 了 窗口 的 滑动 。 

对 于 最 近 3 小 时 的 运行 统计 类 别 ，Storm 同 样 将 其 划分 为 20 个 统计 时 间 窗 口 ， 即 每 个 统计 
窗口 为 540 秒 。 可 以 看 出 ,最 近 10 分 钟 的 运行 统计 类 别 的 窗口 滑动 速度 更 快 ， 统计 结果 也 更 为 
精确 。 

下 面 我 们 分 析 一 下 滑动 窗口 的 数据 结构 以 及 更 新 算法 。 


13.1.1 滑动 窗口 的 数据 结构 
滑动 窗口 里 Storm 实 时 运行 统计 的 基础 ， 本 节 简 要 介绍 一 下 它 的 主要 数据 结构 。 
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1. RollingWindow 
RollingWindow 记 录 定 义 了 一 个 滑动 窗口 : 


(defrecord RollingWindow [updater merger extractor bucket-size-secs num-buckets buckets]) 


其 成 员 变量 分 析 如 下 。 

O updater: 更 新 运行 统计 的 回调 函数 。 

O merger: 获取 数据 时 将 多 个 窗口 的 统计 数据 进行 合并 的 回调 函数 。 

O extractor: 获取 某 一 个 窗口 统计 数据 的 回调 孔 数 。 

口 bucket-size-secs: 窗口 大 小 ， 以 秒 为 单位 ， 该 变量 表示 为 统计 的 最 短 时 间 间 隔 。 
口 num-buckets: 窗口 数量 。 

O buckets: 每 个 窗口 的 统计 数据 ， 为 Map 类 型 。 

下 面 介绍 的 函数 用 于 创建 以 及 操作 RollingWindow 对 象 。 
rolling-window 函 数 用 来 生成 一 个 Rollingwindow 对 象 ， 其 代码 如 下 : 


defn rolling-window [updater merger extractor bucket-size-secs num-buckets 
8 p 8 
RollingWindow. updater merger extractor bucket-size-secs num-buckets 
g p g 


update-rolling-window 函 数 用 来 更 新 RollingWindow， 甚 形 参 依次 为 滑动 窗口 zw、 当 前 的 时 间 


time-secs 和 用 于 统计 更 新 参数 args, 其 中 参数 args 中 将 包含 实际 的 运行 统计 数据 。 该 函数 的 代码 
如 下 : 


1 (defn update-rolling-window 

2 ([^RollingWindow rw time-secs & args] 

3 ;; this is 2.5x faster than using update-in... 

4 (let [time-bucket (curr-time-bucket time-secs (:bucket-size-secs rw)) 
5 buckets (:buckets rw) 

6 curr (get buckets time-bucket) 

7 curr (apply (:updater rw) curr args) 

8 

9 

1 


(assoc rw :buckets (assoc buckets time-bucket curr)) 


0 ))) 


O 第 4 行 利 用 curr-time-bucket 函数 来 获得 当前 时 间 time-secs 所 属 的 时 间 窗 口 序 号 。 
curr-time-bucket 了 负数 的 定义 如 下 : 


defn curr-time-bucket [^Integer time-secs ^Integer bucket-size-secs 
8 8 
(* bucket-size-secs (unchecked-divide-int time-secs bucket-size-secs)) 


) 
而 窗口 序号 是 根据 当前 时 间 time-secs 及 bucket-size-secs 计 算得 到 的 ， 计算 公 式 如 下 : 


#Bucket=bucket-size-secs*(time-secs/bucket-size-secs) 


可 以 看 出 ， 窗 口 序号 并 非 从 零 开 始 ， 而 是 对 bucket-size-secs 进 行 取 整 后 得 到 的 时 间 点 。 
领会 这 一 点 对 于 理解 函数 功能 是 非常 重要 的 。 
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a 第 6 行 根据 窗口 序号 time-bucket 从 滑动 窗口 中 获得 其 对 应 的 窗口 。 

a 第 7 行 调用 滑动 窗口 的 updater 回 调 函 数 ,利用 更 新 参数 对 当前 窗口 进行 更 新 .通常 情况 下 ， 
若 curr 为 空 ， 则 updater 函 数 会 创建 一 个 新 的 窗口 。 

a 第 % 行 将 当前 窗口 curr 与 窗口 序号 time-bucket 绑 定 ， 然 后 存储 在 滑动 窗口 的 buckets 变 量 
value-rolling-window 函 数 用 于 获得 滑动 窗口 所 对 应 的 值 ， 通 常 需 要 将 其 中 各 个 时 间 窗 口 
的 统计 值 进行 合并 ， 其 代码 如 下 : 


1 (defn value-rolling-window [^RollingWindow rw] 
2 ((:extractor rw) 

3 (let [values (vals (:buckets rw))] 

4 (apply (:merger rw) values) 

5 )) 


O 第 3 行 获得 滑动 窗口 的 buckets 哈 希 表 的 值 集合 ， 并 将 结果 存储 到 values 变 量 中 。 
a 第 4 行 利用 滑动 窗口 的 merger 方 法 将 values 中 的 值 合并 ， 然 后 将 结果 返回 。 
cleanup-rolling-window 函 数 用 于 清除 滑动 窗口 中 过 期 的 窗口 ， 其 代码 如 下 : 


1 (defn cleanup-rolling-window [^RollingWindow rw] 

2 (let [buckets (:buckets rw) 

3 cutoff (- (current-time-secs) 

4 (* (:num-buckets rw) 

5 (:bucket-size-secs rw))) 

6 to-remove (filter #(< % cutoff) (keys buckets)) 
7 buckets (apply dissoc buckets to-remove)] 

8 (assoc rw :buckets buckets) 

9 


) 
Q 第 3~4 行 计算 一 个 时 间 点 cutoff， 该 时 间 点 以 前 的 窗口 都 将 被 清除 掉 。 其 计算 方法 如 下 : 
cutoff = current-time-secs - (num-buckets * bucket-size-secs) 
O 第 5 行 获得 要 移 除 的 窗口 序号 ， 它 是 通过 将 时 间 点 cutoff 与 窗口 序号 相 比 较 来 得 到 的 。 
O 第 6 行将 这 些 窗口 序号 所 对 应 的 值 从 哈 希 表 中 清除 。 
rooling-window-size 函 数 用 来 获得 特定 滑动 窗口 所 对 应 的 统计 时 间 间 隔 ， 计 算 方法 为 
window-size = bucket-size-secs * num-buckets。 该 函数 的 实现 如 下 : 


defn rolling-window-size [^RollingWindow rw 
8 8 
(* (:bucket-size-secs rw) (:num-buckets rw))) 


2. RollingWindowSet 

RollingWindowSet 记 录 表 示 一 组 滑动 窗口 ,这 组 滑动 窗口 具有 相同 的 updater 和 extractor 回 调 
方法 : 

(defrecord RollingWindowSet [updater extractor windows all-time]) 


下 面 介 绍 的 函数 用 来 创建 以 及 更 新 滑动 窗口 集合 。 
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rolling-window-set 函 数 用 于 生成 RollingWindowSet 记 录 ， 它 利用 dofor 来 生成 一 组 具有 相同 
窗口 数目 的 滑动 窗口 ， 而 每 个 滑动 窗口 对 应 于 不 同 的 时 间 窗 口 ， 分 别 是 30 秒 、540 秒 以 及 4320 秒 
将 不 同 的 时 间 窗 口 乘 上 对 应 窗口 数目 ( 这 里 是 20 ), 则 滑动 窗口 对 应 的 时 间 间 隔 分 别 是 10 分 钟 、3 
小 时 以 及 1 天 。rolling-window-set 的 代码 如 下 : 


(defn rolling-window-set [updater merger extractor num-buckets & bucket-sizes] 
(RollingWindowSet. updater extractor (dofor [s bucket-sizes] (rolling-window updater merger 
extractor s num-buckets)) nil) 


) 


形 参 num-buckets 是 由 NUM-STAT-BUCKETS 变 量 定义 的 ， 默认 值 为 20， 即 每 个 滑动 窗口 含有 20 个 
小 的 统计 窗口 。 类 似 地 ， 形 参 bucket-sizes 是 由 STAT-BUCKETS 定 义 的 ， 表 示 每 种 类 型 的 滑动 窗口 
的 窗口 大 小 。 相 关 代 人 码 如 下 : 

(def NUM- STAT-BUCKETS 20) 


;; 10 minutes, 3 hours, 1 day 
(def STAT-BUCKETS [30 540 4320]) 


窗口 越 小 ， 则 更 新 越 频繁 ， 统 计数 据 的 准确 性 也 将 更 高 。 
update-TrolLlling-window-set 函 数 通过 调用 update-rolling-window 来 更 新 滑动 窗口 集合 中 的 
每 一 个 滑动 窗口 ， 其 代码 如 下 : 


1 (defn update-rolling-window-set 

2 ([^RollingWindowSet rws & args] 

3 (let [now (current-time-secs) 

4 new-windows (dofor [w (:windows rws)] 

5 (apply update-rolling-window w now args))] 

6 (assoc rws :windows new-windows :all-time (apply (:updater rws) (:all-time rws) args)) 
7 


))) 


注意 在 第 6 行 中 ， 会 调用 滑动 宿 口 集合 zws 的 更 新 回调 函数 updater 对 rws 的 al1-time 关 键 字 进 
行 更 新 。all-time 关 键 字 对 应 于 整个 滑动 窗口 的 总 值 。 

cleanup-rolling-window-set K Zi 3B i: Hi] JH cleanup-rolling-windowym HE fi — ^ 3H 2/] fai O E 
合 中 过 期 的 时 间 和 窗口 ， 其 代码 如 下 : 


(defn cleanup-rolling-window-set 
([^RollingWindowSet rws] 
(let [windows (:windows rws)] 
(assoc rws :windows (map cleanup-rolling-window windows)) 


)) 
value-rolling-window-set PK ZA H]-T 2XURE— “ie oh al A SRA, ER IRI Pede. H 
中 键 为 当前 滑动 窗口 的 窗口 大 小 (例如 10 分 钟 ), 值 为 通过 调用 value-rolling-window 函 数 计 算得 
到 的 值 。 其 代码 如 下 : 


(defn value-rolling-window-set [^RollingWindowSet rws] 
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(merge 
(into {} 
(for [w (:windows rws)] 
{(rolling-window-size w) (value-rolling-window w)} 


)) 
{:all-time ((:extractor rws) (:all-time rws))})) 


13.1.2 ”滑动 窗口 的 回调 函数 


滑动 窗口 中 存储 的 统计 信息 可 以 为 基本 数值 类 型 或 平均 值 类 型 , 它们 分 别 对 应 着 不 同 的 计算 
方法 ， 具体 如 下 所 示 。 

1. 更 新 函数 

Storm 中 定义 了 两 种 类 型 的 更 新 图 数 : 一 种 用 于 更 新 基本 数值 ， 另 外 一 种 用 于 更 新 平均 值 。 

incr-val 函 数 用 于 对 值 进 行 累 加 ， 该 函数 有 两 个 重 载 ， 默 认 的 累加 值 为 1。amap 用 来 存储 运 
行 统 计 结果 ， 若 amap 中 没有 对 应 的 键 ， 则 将 默认 累加 值 初始 化 为 0， 这 通常 对 应 于 新 生成 一 个 统 
计 窗 口 的 情况 。 该 函数 的 代码 如 下 : 


(defn- incr-val 
([amap key] 
(incr-val amap key 1)) 
([amap key amt] 
(let [val (get amap key (long 0))] 
(assoc amap key (+ val amt)) 


)) 
incr-val 函 数 的 第 二 个 重 载 用 于 传人 一 个 amt 值 ， 表 示 增 加 量 。 在 Storm 中 ， 该 值 为 一 个 根据 
采样 频率 估 得 的 值 。 例 如 若 Storm 中 采样 频率 为 5%， 则 该 值 为 0， 即 1 次 更 新 将 相当 于 20 次 更 新 。 
Storm 中 采用 even-sampler 采 样 算法 ， 详 情 请 参考 第 4 章 。 
update-avg 函 数 用 来 更 新 平均 值 。 值 curr 中 的 第 一 部 分 为 累加 值 ， 第 二 部 分 为 消息 的 数目 。 
update-keyed-avg 函 数 用 于 更 新 哈 希 表 中 所 有 的 值 。 相 关 代码 如 下 : 


(defn- update-avg [curr val] 
(if curr 
[(+ (first curr) val) (inc (second curr))] 
[val (long 1)] 


(defn- neg epe [amap key val] 
(assoc amap key (update-avg (get amap key) val))) 
2. 合并 函数 
基本 值 类 型 的 合并 函数 比较 简单 ，Storm 并 没有 额外 定义 一 个 函数 ， 而 是 定义 了 一 个 局 部 函 
数 。Clojure 的 关键 字 partial 用 于 定义 一 个 局 部 函数 。 基 本 值 类 型 的 合并 函数 利用 Clojure 内 置 的 
merge-with 哨 数 进行 累加 。 该 函数 的 定义 如 下 : 


(partial merge-with +) 
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merge-avg 函 数 用 来 计算 合并 后 的 平均 值 。 变 量 avg 中 的 第 一 部 分 为 所 有 的 分 子 第 二 部 分 为 所 
有 的 分 母 , 算法 为 将 分 子 与 分 母 分 别 累加 。merge-keyed-avg 函 数 对 哈 希 表 vals 中 每 一 个 值 对 进行 


计算 。 相 关 代码 如 下 : 


(defn- merge-avg [& avg] 
[(apply + (map first avg)) 
(apply + (map second avg)) 


]) 
(defn- merge-keyed-avg [& vals] 
(apply merge-with merge-avg vals)) 


3. FERN eg BY 
extract-avgPA ZIUHoIe TT ROE (B , extract-keyed-aveg phi SUI MTNA ze vals P Ht — “ME THE 


行 计算 ， 相 关 代 码 如 下 : 


(defn- extract-avg [pair] 
(double (/ (first pair) (second pair)))) 


(defn- extract-keyed-avg [vals] 
(map-val extract-avg vals)) 


基本 值 类 型 的 提取 需 则 比较 简单 ， 直 接 返 回 即 可 ， 其 代码 如 下 : 


(defn- counter-extract [v] 


(if v v {})) 


13.1.3 ”滑动 窗口 集合 的 类 型 
根据 存储 统计 信息 类 型 的 不 同 ，Storm 中 主要 含有 基本 值 类 型 和 平均 值 类 型 这 两 种 滑动 窗口 
集合 类 型 


全 类型。 基本 值 类 型 的 滑动 窗口 集合 可 用 来 统计 发 送 的 消息 总 数 , 即 平均 值 类 型 的 滑动 窗口 集 


合 则 可 用 来 统计 发 送 消息 的 平均 时 延 。 
keyed-counter-rolling-window-set 函 数 用 于 定义 基本 值 类 型 的 滑动 窗口 集合 ， 其 代码 如 下 : 


(defn keyed-counter-rolling-window-set [num-buckets & bucket-sizes] 
(apply rolling-window-set incr-val (partial merge-with +) counter-extract num-buckets 


bucket-sizes)) 


avg-rolling-window-set 消 数 用 于 定义 平均 值 类 型 的 滑动 窗口 集合 ， 其 代码 如 下 : 


(defn avg-rolling-window-set [num-buckets & bucket-sizes] 
(apply rolling-window-set update-avg merge-avg extract-avg num-buckets bucket-sizes) 


f. XR 


keyed-avg-rolling-window-set 函 数 用 于 定义 哈 希 表 上 的 平均 值 类 型 的 滑动 窗口 集合 ， 其 


人 码 如 下 : 


(defn keyed-avg-rolling-window-set [num-buckets & bucket-sizes] 
(apply rolling-window-set update-keyed-avg merge-keyed-avg extract-keyed-avg num-buckets 


bucket-sizes)) 
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这 几 种 滑动 窗口 集合 的 本 质 区 别 在 于 其 滑动 窗口 中 存储 数据 的 类 型 不 同 , 并 且 它 们 需要 采用 
不 同 的 回调 函数 进行 操作 ， 具 体 情 况 如 表 13-1 所 示 。 
表 13-1 ”滑动 窗口 集合 的 类 型 
keyed-counter-rolling-window-set avg-rolling-window-set keyed-avg-rolling-window-set 

统计 窗口 中 存储 的 BEK 一 个 <Key, Value> 值 对 BEK 

数据 类 型 值 为 简单 类 型 键 为 Sum 值 为 <Sum, Count> 对 
值 为 Count 
Avg=Sum/Count 

更 新 函数 incr-val update-avg update-keyed-avg 

合并 函数 (partial merge-with +) merge-avg merge-keyed-avg 

提取 函数 counter-extract extract-avg extract-keyed-avg 


window-set 类 


型 的 滑动 窗口 集合 


在 许多 函数 中 ， 可 以 对 关键 字 : 


all-time 进 行 操作 ， 例 如 update-rolling-window-set 是 滑动 
窗口 的 含有 的 统计 汇总 ， 其 数据 类 型 与 小 统计 窗口 相同 。 

在 Storm 中 ,我们 主要 采 keyed-counter-rolling-window-set 以 及 keyed-avg-Tolling- 
统计 窗口 中 哈 希 表 的 键 为 组 件 的 流 号 〈 StreamId )。 


13.2 Storm 中 的 统计 信息 


类 别 及 其 更 新 时 机 ,这 


表 13-2 ”Storm 中 的 统计 类 别 


文 对 于 理解 Storm UI 上 所 展示 的 内 容 


s 别 的 统计 都 对 应 着 一 个 滑动 时 间 窗 口 集合 对 象 ， 具 体 如 表 13-2 所 示 。 


类 


型 


更 新 函数 


本 节 将 分 析 Storm 中 含有 的 统计 信息 
至 关 重 要 。 
13.2.1 Stats 中 定义 的 统计 类 别 
在 Storm 中 ， 每 种 类 
统计 名 称 类 3 
:emitted COMMON-FIELDS 
:transferred COMMON-FIELDS 
:acked BOLT 
:failed BOLT 
:process-latencies BOLT 
:executed BOLT 
:execute-latencies BOLT 
:acked SPOUT 
:failed SPOUT 
:complete-latencies SPOUT 


其 中 COMMON-FIELDS 表 示 Spout 和 Bolt 都 具有 的 统计 类 别 。 详 情 可 参考 源 代码 中 mk-spout-stats 


以 及 make-bolt-stats 消 数 的 定义 。 


keyed-counter-roll 


ing-window-set 


keyed-counter-rolling-window-set 


keyed-counter-roll 
keyed-counter-roll 
keyed-avg-rolling- 
keyed-counter-roll 
keyed-avg-rolling- 
keyed-counter-roll 
keyed-counter-roll 


keyed-avg-rolling- 


ing-window-set 
ing-window-set 
window-set 

ing-window-set 
window-set 

ing-window-set 
ing-window-set 


window-set 


emitted-tuple! 
transferred-tuples! 
bolt-acked-tuple! 
bolt-failed-tuple! 
bolt-acked-tuple! 
bolt-execute-tuple! 
bolt-execute-tuple! 
spout-acked-tuple! 
spout-failed-tuple! 
spout-acked-tuple! 
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13.2.2 ”运行 统计 的 更 新 


Storm 中 定义 了 一 个 宏 来 更 新 这 些 统计 信息 ， 该 宏 的 含义 为 ， 从 stats 对 象 中 根据 path 定 义 的 
关键 字 来 获取 其 对 应 的 滑动 窗口 集合 ， 然 后 传人 args 参 数 ， 再 调用 update-rolling-window-set 方 
法 对 滑动 窗口 集合 进行 更 新 ， 其 中 stats 对 和 象 为 Storm 中 的 滑动 窗口 集合 ，path 为 统计 类 别 ( fil 
如 :acked )。 下 面 的 宏 可 以 完成 此 功能 : 


(defmacro update-executor-stat! [stats path & args] 
(let [path (collectify path)] 
(swap! (-» "stats ~@path) update-rolling-window-set ~@args) 


) 
在 Storm 中 ， 我 们 定义 了 诸如 spout-acked-tuple! 的 函数 来 更 新 滑动 窗口 集合 。Storm 将 在 合 
适 的 时 间 点 去 调用 这 些 函 数 。 


13.2.3 ”运行 统计 的 更 新 时 间 点 


运行 统计 对 于 Storm 来 讲 是 至 关 重 要 的 ， 但 过 多 的 运行 统计 操作 会 降低 系统 的 吞吐 量 。 在 
Storm 中 ， 我 们 采用 采样 的 方式 并 根据 这 部 分 统计 的 结果 来 估计 全 局 统计 结果 。 在 Storm 中 ，UI 
上 反映 出 来 的 统计 信息 为 全 局 统计 结果 , 不 过 它 是 根据 采样 结果 估计 得 到 的 。 在 本 节 中 , 我们 介 
绍 一 下 Storm 是 如 何在 系统 中 藤 人 这 些 运 行 统计 代码 的 。 

Storm 定 义 了 一 些 采样 函数 ， 相 关 代码 如 下 : 


:sampler (mk-stats-sampler storm-conf) 
execute-sampler (mk-stats-sampler (:storm-conf executor-data)) 
emit-sampler (mk-stats-sampler storm-conf) 


其 中 变量 : sampler 是 Executor 的 数据 变量 , 变量 execute-sampler 在 Bolt 的 主线 程 循环 中 定义 ， 
而 emit-sampler 是 在 Task 的 数据 变量 。 这 些 采样 函数 的 实例 将 用 于 不 同 的 统计 目的 。 
mk-stats-sampler 了 基数 将 产生 一 个 均匀 采样 名 实例 ( even-sampler )。 

本 节 接 下 来 的 部 分 将 对 Storm 中 的 运行 统计 更 新 函数 及 其 调用 时 机 展开 讨论 。 

1. bolt-execute-tuple! EK Zi 
对 于 Bolt 类 型 的 Executor ， 其 tuple-action-fn 函 数 将 调用 Bolt 对 象 的 execute 方 法 。 调 用 
execute 方 法 前 后 是 对 一 些 运 行 统计 进行 更 新 的 合适 时 机 。 下 面具 体 来 看 一 下 这 些 运 行 统计 代码 
是 如 何 和 能 入 到 系统 中 的 : 


1 (let [task-data (get task-datas task-id) 

2 ^IBolt bolt-obj (:object task-data) 

3 user-context (:user-context task-data) 

4 sampler? (sampler) 

5 execute-sampler? (execute-sampler) 

6 now (if (or sampler? execute-sampler?) (System/currentTimeMillis))] 
7 (when sampler? 

8 (.setProcessSampleStartTime tuple now)) 
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9 (when execute-sampler? 

10 (.setExecuteSampleStartTime tuple now)) 

11  (.execute bolt-obj tuple) 

12 (let [delta (tuple-execute-time-delta! tuple)] 


13 (task/apply-hooks user-context .boltExecute (BoltExecuteInfo. tuple task-id delta)) 
14 (when delta 

15 (builtin-metrics/bolt-execute-tuple! (:builtin-metrics task-data) 
16 executor-stats 

17 (.getSourceComponent tuple) 

18 (.getSourceStreamId tuple) 

19 delta) 

20 (stats/bolt-execute-tuple! executor-stats 

21 (.getSourceComponent tuple) 

22 (.getSourceStreamId tuple) 

23 delta))))))] 


a 第 4 行 调用 采样 器 sampler 来 计算 本 条 消息 是 否 被 采样 ， 若 被 采样 ， 将 调用 输入 消息 的 
setProcessSampleStartTime 方 法 设置 消息 的 处 理 开始 时 间 。 消 息 的 处 理 时 间 与 消息 的 执行 
时 间 是 不 同 的 概念 ， 前 者 表示 从 收 到 该 消息 到 该 消息 进行 Ack 或 Fail 操 作 的 时 间 间 隔 ， 而 
后 者 则 表示 整个 execute 函 数 的 执行 时 间 。 通 常 ， 这 两 个 值 是 比较 接近 的 。 

a 第 5 行 调用 采样 函数 execute-sampler， 来 确定 本 条 消息 是 否 被 采样 。 

a 在 第 9~10 行 中 ， 若 采样 则 调用 输入 消息 的 setExecuteSampleStartTime 方 法 来 设置 execute 

函数 的 调用 开始 时 间 。 

O 在 第 12 行 中 ， 者 delta 不 为 空 ， 则 表明 该 消息 被 采样 了 。 

a 第 13 行 调用 用 户 实现 的 钓 子 方法 ， 这 与 系统 的 运行 统计 无 关 ， 不 过 此 时 用 户 可 以 实现 钓 

子 方法 来 获得 运行 统计 信息 。 

a 第 15~19 行 调用 builtin-metrics/bolt-execute-tuple! 更 新 内 置 统计 信息 ， 其 中 内 置 的 统 

计 信 息 将 在 下 一 章 中 讨论 。 

a 第 20~23 行 调用 stats/bolt-execute-tuplel! 函 数 更 新 统计 信息 。 

2. bolt-acked-tuplel! 函 数 
Bolt 类 型 Executor 的 bolt-acked-tuple! 函 数 在 消息 进行 Ack 操 作 时 调用 ， 以 获取 Ack 的 消息 数 
目 以 及 消息 的 处 理 时 延 等 统计 信息 ， 相 关 代码 如 下 : 
(^void ack [this ^Tuple tuple] 
(let [^TupleImpl tuple tuple 
ack-val (.getAckVal tuple) ] 
(fast-map-iter [[root id] (.. tuple getMessageId getAnchorsTolds) ] 


1 
2 
3 
4 
5 (task/send-unanchored task-data 
6 ACKER-ACK-STREAM- ID 
7 
8 
9 
1 


[root (bit-xor id ack-val)]) 


(let [delta (tuple-time-delta! tuple) ] 


0 (task/apply-hooks user-context .boltAck (BoltAckInfo. tuple task-id delta)) 
11 (when delta 
12 (builtin-metrics/bolt-acked-tuple! (:builtin-metrics task-data) 


13 executor-stats 
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14 (.getSourceComponent tuple) 

15 (.getSourceStreamId tuple) 

16 delta) 

17 (stats/bolt-acked-tuple! executor-stats 
18 (.getSourceComponent tuple) 

19 (.getSourceStreamId tuple) 

20 delta)))) 


口 第 9% 行 调用 tuple-time-deltal! 函 数 计 算 消 息 的 处 理 时 间 。 在 Bolt 的 execute 函 数 中 ， 若 消息 
被 sampler， 采 样 器 采样 ， 则 设 定 processSampleStartTime。 当 该 消息 被 Ack 时 ， 则 判断 
process SampleStartTime 是 否 为 空 ， 若 不 为 空 则 计算 消息 的 处 理 时 间 。 可 见 ， 消 息 的 处 理 
时 间 是 跨 节 点 计算 的 ， 而 执行 时 间 是 在 同一 节点 中 计算 得 到 的 。 

a 第 10~20 行 调用 钧 子 方法 以 及 运行 统计 的 更 新 函数 更 新 相应 的 运行 统计 。tuple-time- 
deltal 的 定义 如 下 : 

(defn- tuple-time-delta! [^TupleImpl tuple] 
(let [ms (.getProcessSampleStartTime tuple)] 


(if ms 
(time-delta-ms ms)))) 


3. bolt-failed-tuplel! 函 数 
类 似 地 , 在 Bolt 类 型 Executor 的 fail 方 法 中 , 将 调用 bolt-failed-tuple! 更 新 函数 。 是 否 进行 运 
行 统计 更 新 同样 取决 于 采样 器 sampler。 下 面 的 代码 演示 了 fail 方 法 是 如 向 和 能 入 运行 统计 代码 的 : 


(^void fail [this ^Tuple tuple] 
(fast-list-iter [root (.. tuple getMessageId getAnchors)] 
(task/send-unanchored task-data 
ACKER-FAIL-STREAM-ID 
[root])) 
(let [delta (tuple-time-delta! tuple)] 
(task/apply-hooks user-context .boltFail (BoltFailInfo. tuple task-id delta)) 
(when delta 
(builtin-metrics/bolt-failed-tuple! (:builtin-metrics task-data) 
executor-stats 
(.getSourceComponent tuple) 
(.getSourceStreamId tuple) ) 
(stats/bolt-failed-tuple! executor-stats 
(.getSourceComponent tuple) 
(.getSourceStreamId tuple) 
delta)))) 


4. transferrred-tuple!#lemitted-tuple! ay 
这 两 个 函数 主要 在 Task 的 发 送 孔 数 中 调用 ，Spout 或 Bolt 的 Executor 在 发 送 消 息 时 都 会 通过 
Task 的 发 送 函 数 来 实现 ， 相 关 代码 如 下 : 


1 (fn ([^Integer out-task-id ^String stream ^List values] 

2 (when debug? 

3 (log-message "Emitting direct: " out-task-id "; " component-id " " stream 
4 (let [target-component (.getComponentId worker-context out-task-id) 


values)) 
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5 component-»grouping (get stream-»component-»grouper stream) 
6 grouping (get component-»grouping target-component) 
7 out-task-id (if grouping out-task-id)] 
8 (when (and (not-nil? grouping) (not- :direct grouping)) 
9 (throw (IllegalArgumentException. "Cannot emitDirect to a task expecting a regular 
grouping"))) 
10 (apply-hooks user-context .emit (EmitInfo. values stream task-id [out-task-id])) 
11 (when (emit-sampler) 
12 (builtin-metrics/emitted-tuple! (:builtin-metrics task-data) executor-stats 
stream) 
13 (stats/emitted-tuple! executor-stats stream) 
14 (if out-task-id 
15 (stats/transferred-tuples! executor-stats stream 1) 
16 (builtin-metrics/transferred-tuple! (:builtin-metrics task-data) 
executor-stats stream 1))) 
17 (if out-task-id [out-task-id]) 
18 )) 
19  ([^String stream ^List values] 
20 (when debug? 
21 (log-message "Emitting: " component-id " " stream " " values)) 
22 (let [out-tasks (ArrayList.)] 
23 (fast-map-iter [[out-component grouper] (get stream->component->grouper stream) ] 
24 (when (= :direct grouper) 
25 33 TODO: this is wrong, need to check how the stream was declared 
26 (throw (IllegalArgumentException. "Cannot do regular emit to direct 
stream"))) 
27 (let [comp-tasks (grouper task-id values) ] 
28 (if (or (sequential? comp-tasks) (instance? Collection comp-tasks)) 
29 (.addAll out-tasks comp-tasks) 
30 (.add out-tasks comp-tasks) 
31 )) 
32 (apply-hooks user-context .emit (EmitInfo. values stream task-id out-tasks)) 
33 (when (emit-sampler) 
34 (stats/emitted-tuple! executor-stats stream) 
35 (builtin-metrics/emitted-tuple! (:builtin-metrics task-data) executor-stats 
stream) 
36 (stats/transferred-tuples! executor-stats stream (count out-tasks)) 
37 (builtin-metrics/transferred-tuple! (:builtin-metrics task-data) executor-stats 
stream (count out-tasks))) 
38 out-tasks))) 
39 


O 第 4~18 行 对 应 于 向 直接 流 发 送 消息 。 在 第 11 行 中 , E FEdRemit-sampler2ytrue, MAJA 
emitted-tuple! 更 新 发 送 的 消息 数目 ; 若 含 有 out-task-id， 则 调用 transferred-tuplesl 


传输 六 


HE. 可 以 看 出 , 知 目 标 节 点 没有 收听 该 直接 流 , 则 emitted-tuple! 会 被 调用 , 而 trans 


ferred-tuplel! 不 会 被 调用 ， 即 该 消息 实际 上 并 没有 被 传输 ， 从 这 一 点 也 可 看 出 这 两 个 统 
计 的 差别 。 

O 第 19~38 行 用 于 向 目标 节点 集合 发 送 消息 。 第 33~37 行 用 于 更 新 统计 信息 。 知 含有 多 个 接 
则 emitted-tuple! 函 数 只 算 一 aie dioi Qe tuple! 则 被 算 作 多 条 消 


息 。 传 输 的 消息 数目 反映 了 实际 传输 的 消息 数目 。 这 也 是 两 个 函数 定义 略 有 区 别 的 原因 。 
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这 两 个 函数 的 代码 如 下 : 
(defn emitted-tuple! [stats stream] 
(update-executor-stat! stats [:common :emitted] stream (stats-rate stats))) 


defn transferred-tuples! [stats stream amt 
p 
(update-executor-stat! stats [:common :transferred] stream (* (stats-rate stats) amt))) 


transferred-tuples ! PAZ rt; 2f A amt , 它 通 过 计算 (stats-Tate stats)*amt 来 获得 更 新 数量 ， 
而 emitted-tuple! 则 使 用 (stats-rate stats) 作 为 更 新 数量 。 

5. spout-acked-tuple!#lspout-failed-tuple! ey a 

这 两 个 函数 会 在 Spout 节 点 收 到 消息 的 Ack 或 Fail 时 被 调用 , 这 表明 只 有 当 Spout 打 开 消 息 跟 踪 
时 ， 两 类 统计 信息 才 会 被 更 新 。send-spout-msg 将 决定 一 条 消息 是 否 被 运行 统计 选中 ， 下 面 分 析 
该 函数 的 代码 : 


1 (if rooted? 


2 (do 

3 (.put pending root-id [task-id 

4 message-id 

5 {:stream out-stream-id :values values} 
6 (if (sampler) (System/currentTimeMillis))]) 
7 (task/send-unanchored task-data 

8 ACKER-INIT-STREAM-ID 

9 [root-id (bit-xor-vals out-ids) task-id] 

10 overflow-buffer)) 

11 (when message-id 

12 (ack-spout-msg executor-data task-data message-id 

13 {:stream out-stream-id :values values} 

14 (if (sampler) 0)))) 


15 (or out-tasks []) 

a 第 6 行 调 用 采样 器 sampler， 若 返回 为 ture， 则 设置 为 当前 时 间 ， 否 则 为 空 。 

a 在 第 14 行 中 ， 当 消息 被 跟踪 ， 但 系统 却 没有 Acker Bolt 节 点 时 ， 消 息 将 直接 被 Spout 节 点 
Ack。 若 该 消息 被 采样 器 选中 ， 统 计数 据 也 会 被 更 新 。 

接 下 来 分 析 ack-spout-msg 函 数 ， 相 关 代码 如 下 : 


1 (defn- ack-spout-msg [executor-data task-data msg-id tuple-info time-delta] 

2 (let [storm-conf (:storm-conf executor-data) 

3 ^ISpout spout (:object task-data) 

4 task-id (:task-id task-data)] 

5 (when (= true (storm-conf TOPOLOGY-DEBUG)) 

6 (log-message "Acking message " msg-id)) 

7 (.ack spout msg-id) 

8 (task/apply-hooks (:user-context task-data) .spoutAck (SpoutAckInfo. msg-id task-id 
time-delta)) 


9 (when time-delta 

10 (builtin-metrics/spout-acked-tuple! (:builtin-metrics task-data) (:stats 
executor-data)(:stream tuple-info) time-delta) 

11 (stats/spout-acked-tuple! (:stats executor-data) (:stream tuple-info) time-delta)))) 


若 输入 的 time-delta 不 为 空 , 则 调用 spout-acked-tuple! 来 更 新 统计 。time-delta 通 过 下 面 代 
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码 中 的 方法 得 到 , 若 start-time-ms 不 为 空 , 则 用 当前 时 间 减 去 start-time-ms。( 变量 start-time-ms 
是 在 sent-spout-msg 函 数 中 根据 是 否 被 采样 选中 而 设置 的 ): 


[time-delta (if start-time-ms (time-delta-ms start-time-ms))] 


13.2.4 获取 统计 数据 


cleanup-stats! 函 数 用 来 通知 滑动 窗口 进行 滑动 ， 这 样 过 期 的 统计 窗口 将 被 清除 ， 相 关 代 码 
如 下 : 

(defn- cleanup-stat! [stat] 

(swap! stat cleanup-rolling-window-set)) 

Storm 在 获取 统计 信息 时 , 会 首先 调用 窗口 滑动 函数 ,然后 再 获取 当前 的 统计 值 。 也 就 是 说 ， 
在 Storm 获 取 统 计 信 息 之 前 , 每 个 滑动 窗口 的 实际 统计 窗口 数目 可 能 大 于 预定 义 的 统计 窗口 数目 。 
cleanup-spout-stats! 和 cleanup-bolt-stats! 函 数 分 别 用 于 清理 Spout 和 Bolt 中 各 个 统计 信息 的 滑 
动 窗口 集合 。 

value-bolt-stats! 函 数 用 来 获取 统计 信息 ， 相 关 代码 如 下 : 


(defn- value-common-stats [^CommonStats stats] 
(merge 
(value-stats stats COMMON-FIELDS) 
{:rate (:rate stats)})) 


(defn value-bolt-stats! [^BoltExecutorStats stats] 
(cleanup-bolt-stats! stats) 
(merge (value-common-stats (:common stats)) 
(value-stats stats BOLT-FIELDS) 
{:type :bolt})) 
value-stats KAHK RA Ph STR AY is, 其 返回 结果 是 一 个 哈 希 表 , 键 为 统计 
型 ， 值 为 统计 结果 。 值 的 类 型 也 为 哈 希 表 ， 表 示 每 个 流 上 的 统计 值 。 另 外 ， 关 键 字 :type 表示 
点 类 型 ，:rate 表 示 为 采样 频率 。 
render-stats! 会 函数 调用 value-bolt-stats! 及 value-spout-stats! 来 获取 统计 信息 ， 相 关 代 
人 码 如 下 : 


(defmulti render-stats! class-selector) 


(defmethod render-stats! SpoutExecutorStats [stats] 
(value-spout-stats! stats)) 


(defmethod render-stats! BoltExecutorStats [stats] 
(value-bolt-stats! stats)) 


Storm 的 运行 统计 结果 会 通过 心跳 的 方式 传送 到 ZooKeeper， 而 Nimbus 从 ZooKeeper 中 获取 这 
些 信息 并 在 Storm UI 进行 展示 。 具 体 地 ，Worker 中 会 调用 如 下 方法 : 
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1 (defnk do-executor-heartbeats [worker :executors nil] 

2 ;; Stats is how we know what executors are assigned to this worker 

3 (let [stats (if-not executors 

4 (into {} (map (fn [e] {e nil}) (:executors worker))) 

5 (-»» executors 

6 (map (fn [e] ((executor/get-executor-id e) (executor/render-stats e)})) 
7 (apply merge))) 

8 zk-hb {:storm-id (:storm-id worker) 


9 :executor-stats stats 

10 :uptime ((:uptime worker)) 

11 :time-secs (current-time-secs) 

12 

13 33 do the zookeeper heartbeat 

14 (.worker-heartbeat! (:storm-cluster-state worker) (:storm-id worker) (:assignment-id 


worker) (:port worker) zk-hb) 
15 ) 
其 中 第 6 行 调用 每 一 个 Executor 的 render-stats 方 法 来 获得 该 Executor 的 运行 统计 信息 (这 个 
方法 实际 上 调用 了 stats.clj 中 的 render-stats! 方 法 )。 之 后 ， 利 用 统计 信息 构成 Executor 的 心跳 信 
息 发 送出 去 。 
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各 个 节点 的 运行 统计 结果 存储 在 ZooKeeper 中 ,而 Nimbus 从 ZooKeeper 中 获得 这 些 结果 将 其 显 
示 在 StormUI 上 。Nimbus 采 用 Thrift 结 果 来 存储 这 些 运 行 统计 信息 。 下 面 简要 介绍 这 些 数据 结构 。 

Storm 中 定义 了 Thrift 类 型 的 数据 结构 BoltStats 和 SpoutSstats， 统 计 信息 需要 放 和 人 这 两 种 类 型 
的 对 象 中 。Nimbus 会 调用 相关 函数 来 将 这 些 对 象 初始 化 。 

to-global-stream-id 函 数 根据 组 件 以 及 流 来 构建 Globalstream 对 象 ， 其 中 GlobalStream 对 和 象 
为 流 的 全 局 标识 符 ， 其 代码 如 下 : 


(defn to-global-stream-id [[component stream]] 
(GlobalStreamId. component stream)) 


window-set-converterPKZifry 3:98 H Bd FJ EjalobalstreamXd Jw HJ TT [E « stats] 8 I] PEAY 
关系 为 bucketsize->[ComponentId，StreamId]->Value。 下 面 看 一 下 该 函数 的 实现 : 


(defn window-set-converter 
([stats key-fn] 
;; make the first key a string, 
(into {} 
(for [[k v] stats] 
[(str k) 
(into {} 
(for [[k2 v2] v] 
[(key-fn k2) v2]))] 


([stats] 
(window-set-converter stats identity))) 
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thriftify-specific-stats:bolt 函 数 为 Bolt 类 型 的 函数 实现 , 它 将 Bolt 中 各 种 类 型 的 统计 信 ， 


转化 成 为 Thrift 中 定义 的 类 型 ， 相 关 代码 如 下 : 


(defmethod thriftify-specific-stats :bolt 
[stats] 
(ExecutorSpecificStats/bolt 
(BoltStats. (window-set-converter (:acked stats) to-global-stream-id) 

(window-set-converter (:failed stats) to-global-stream-id) 
(window-set-converter (:process-latencies stats) to-global-stream-id) 
(window-set-converter (:executed stats) to-global-stream-id) 
(window-set-converter (:execute-latencies stats) to-global-stream-id) 


))) 


wy 


系统 运行 统计 的 另 一 种 实现 


除了 上 一 章 介 绍 的 内 容 外 ，Storm 还 提供 了 另 一 种 运行 统计 的 方法 ， 我 们 称 之 为 内 置 的 运行 
统计 。 未 来 ，Storm 可 能 会 采取 这 种 方式 收集 运行 统计 信息 。 这 些 内 置 的 运行 统计 与 目前 正在 使 
用 的 运行 统计 类 似 , 它们 都 包括 了 诸如 每 个 组 件 发 送 的 消息 数目 和 处 理 时 延 等 信息 , 但 内 署 的 运 
行 统计 却 是 通过 不 同 的 处 理 机 制 才 收集 到 这 些 统计 数据 的 。 总 的 来 说 , 内置 统计 信息 的 收集 有 如 
下 几 个 主要 步 又 。 

(1) 创建 Task 数 据 时 ， 系 统 会 将 内 置 的 统计 类 别 注 册 到 该 Task 所 对 应 的 TopologyContext 对 
象 中 。 

(2) 创建 Executor 时 会 创建 一 个 计时 器 ， 该 计时 需 将 定期 向 流 METRICS_TICK_STREAM_ID 发 送 统 
计 触 发 消息 C Tick )。 

(3) Task 收 到 统计 触发 消息 后 ， 会 将 Task 中 注册 的 统计 类 别 的 结果 发 送 到 流 METRICS_STREAM_ID 
上 去 。 于 是 ， 系 统 中 的 任何 一 个 组 件 都 会 向 该 流 发 送 统 计 结 果 消 息 。 

(4) 用 户 创 建 一 个 类 实现 IMetricsConsumer 接 口 ， 并 将 该 类 注册 到 Storm 中 ， 这 需要 通过 参数 
TOPOLOGY_METRICS_CONSUMER_REGISTER 以 及 类 Config 的 registerMetricsConsumer 来 完成 。 

(5) 当 系 统 中 存在 已 注册 的 IMetricsConsumer 类 时 ,Storm 将 为 每 一 个 类 创建 一 个 Bolt 节 点 , 该 
Bolt 节 点 负责 收听 所 有 组 件 发 送 到 METRICS_STREAM_ID 的 消息 。 

(6) 每 个 Worker 都 会 创建 一 个 SystemBolt， 该 Bolt 节 点 会 将 其 所 在 进程 的 内 存 统计 、Java 垃 圾 
回收 等 信息 发 送 到 METRICS_STREAM_ID, 于 是 IMetricsConsumer Bolt 节 点 便 也 可 以 收 到 这 些 消息 了 。 

从 上 面 的 步 缀 可 以 看 出 ，Storm 中 可 以 存在 全 局 的 Bolt 节 点 , 以 收集 这 些 运行 统计 结果 。 (AA 
前 ，Storm 并 没有 添加 此 类 默认 的 运行 统计 收集 节点 。 对 于 本 章 ， 读 者 可 以 选择 性 地 阅读 。 


14.4 内 置 统计 信息 的 计算 


内 置 的 运行 统计 主要 有 两 种 类 型 : 一 种 是 计数 类 型 的 ， 如 发 送 的 消息 数目 、 被 Ack 的 消息 数 
AS; 另外 一 种 是 时 延 类 型 的 , 如 消息 的 平均 处 理 时 延 等 。Storm 提 供 了 一 套 较 为 灵活 的 API 系 统 ， 
可 以 帮助 用 户 实现 自 定 义 的 统计 信息 , 以 及 将 它们 注册 到 TopologyContext 中 。 内 置 统 计 信息 的 类 
关系 如 图 14-1 所 示 。 
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图 14-1 ”内置 统 计 信息 的 类 关系 
这 些 接 口 较为 简单 , 读者 可 以 参考 其 源 代码 进行 学 习 , 本 节 主 要 对 其 中 几 个 较为 重要 的 类 进 


介绍 。 


i 


14.1.1 MultiCountMetric 


CountMetric 类 内 含 一 个 long 类 型 的 值 ， 并 提供 incr 和 incrBy 方 法 来 对 该 值 进行 更 新 。 

MultiCountMetric 类 含有 一 组 CountMetric 对 象 , 该 类 在 更 新 时 , 会 通过 调用 scope 函 数 来 找到 
相应 的 CountMetric 对 象 。 在 Storm 中 ，scope 常 作为 流标 识 符 存在 ， 即 ComponentId:StreamId。 

例如 ， 在 统计 Spout 发 送 的 消息 条 数 时 ， 由 于 Spout 可 以 向 多 个 流 发 送 消 息 ， 需 对 它们 分 开 进 
行 统 计 ， 因 此 需要 用 MultiCountMetric 类 来 处 理 ， 这 也 体现 了 MulticountMetric 类 的 设计 目标 。 
该 类 的 实现 如 下 : 


public class MultiCountMetric implements IMetric { 
Map«String, CountMetric> value = new HashMap(); 


public MultiCountMetric() { 
} 


public CountMetric scope(String key) { 
CountMetric val = value.get(key); 
if(val == null) { 
_value.put(key, val = new CountMetric()); 


return val; 


} 


public Object getValueAndReset() { 
Map ret = new HashMap(); 
for(Map.Entry«String, CountMetric» e : value.entrySet()) { 
ret.put(e.getKey(), e.getValue().getValueAndReset()); 
} 


return ret; 
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} 
public class CountMetric implements IMetric { 
long value = 0; 


public CountMetric() ( 
) 


public void incr() { 
| values; 
) 


public void incrBy(long incrementBy) { 
. value += incrementBy; 
) 


public Object getValueAndReset() { 
long ret - value; 
_value = 0; 
return ret; 


14.1.2 MultiReducedMetric 


MeanReducer 类 用 来 计算 平均 值 。 例 如 ， 在 更 新 消息 的 平均 处 理 时 间 时 ，Storm 所 获得 的 信息 
为 单条 消息 的 处 理 时 间 ， 这 种 情况 下 便 可 使 用 MeanReducer 类 保存 总 处 理 时 间 以 及 消息 条 数 ， 继 
而 方便 地 计算 出 平均 时 间 。 

MultiReducedMetric 类 含有 一 组 ReducedMetric 对 象 。 目 前 ，Storm 采 用 MeanReducer 作 为 其 实 
现 。 该 类 的 目标 与 MultiCountMetric 相 同 ， 是 为 了 区 分 同一 个 组 件 上 不 同 流 的 统计 结果 。 该 类 的 
实现 如 下 : 


public class MultiReducedMetric implements IMetric { 
Map«String, ReducedMetric» value = new HashMap(); 
IReducer reducer; 


public MultiReducedMetric(IReducer reducer) { 
 reducer - reducer; 
) 


public ReducedMetric scope(String key) { 
ReducedMetric val - value.get(key); 
if(val == null) ( 
_value.put(key, val = new ReducedMetric( reducer)); 
} 


return val; 


} 


public Object getValueAndReset() { 
Map ret = new HashMap(); 
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for(Map.Entry«String, ReducedMetric» e : value.entrySet()) { 
Object val = e.getValue().getValueAndReset(); 
if(val != null) { 
ret.put(e.getKey(), val); 
) 


} 


return ret; 


} 


class MeanReducerState { 
public int count = 0; 
public double sum = 0.0; 


} 


public class MeanReducer implements IReducer<MeanReducerState> { 
public MeanReducerState init() { 
return new MeanReducerState(); 
} 


public MeanReducerState reduce(MeanReducerState acc, Object input) { 
acc.count++; 
if(input instanceof Double) { 
acc.sum += (Double) input; 
} else if(input instanceof Long) { 
acc.sum += ((Long)input) .doubleValue() ; 
} else if(input instanceof Integer) { 
acc.sum += ((Integer) input) .doubleValue(); 
} else { 
throw new RuntimeException( 
"MeanReducer::reduce called with unsupported input type 


"> 


+ "`. Supported types are Double, Long, Integer."); 


* input.getClass() 


} 


return acc; 


} 


public Object extractResult(MeanReducerState acc) { 
if(acc.count > 0) ( 
return new Double(acc.sum / (double)acc.count) ; 
} else { 
return null; 
} 


14.2 内置 统计 类 型 


Spout 与 Bolt 对 应 着 相似 的 统计 类 型 ,但 二 者 略 有 区 别 。 例 如 ，Spout 和 Bolt 都 含有 消息 被 Ack 
WEA, 但 只 有 Bolt 含 有 执行 数目 统计 信息 ( execute-count )。 本 节 将 分 别 对 两 种 类 型 的 内 置 统计 
进行 讨论 。 而 运行 统计 的 更 新 时 机 与 上 一 章 讨论 的 内 容 相 同 ， 本 章 不 再 袭 述 。 
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14.2.1 ” Spout 类 型 的 内 置 统计 
表 14-1 列 出 了 与 Spout 相 对 应 的 统计 类 型 及 其 更 新 方法 。 
表 14-1 Spout 的 内 置 统计 类 型 


名 HW 类 型 更 新 方法 fa xk 
ack-count MultiCountMetric spout-acked-tuple! Ack 数 目 
complete-latency MultiReducedMetric spout-acked-tuple! 处 理 时 延 
fail-count MultiCountMetric spout-failed-tuple! 失败 数 牛 
emit-count MultiCountMetric emitted-tuple! 发 送 数 
transfer-count MultiCountMetric transferred-tuple! 传输 数 E 
emit-count 指 的 是 一 个 组 件 发 送 的 消息 数 。 但 在 某 些 情况 下 ， 一 条 消息 要 被 复制 多 份 再 发 送 


出 去 ， 这 时 transfer-count 则 可 表示 实际 的 消息 传输 数目 。 例 如 ， 子 节点 以 全 局 分 组 的 方式 接收 
某 一 个 流 , 那么 该 流 中 的 一 条 消息 将 被 发 送 到 所 有 子 节 点 上 ， 传 输 数 目 为 接收 子 节点 的 数目 ， 即 
同一 条 消息 被 发 送 多 次 。 
14.2.2 Bolt 类 型 的 内 置 统 计 
表 14-2 列 举 出 了 与 Bolt 相 对 应 的 统计 类 型 及 其 更 新 方法 。 
表 14-2 ”Bolt 的 内 置 统计 类 型 


名 HW 类 g 更 新 方法 fa xk 
ack-count MultiCountMetric bolt-acked-tuple! Ack% E 
process-latency MultiReducedMetric bolt-acked-tuple! 处 理 时 延 
fail-count MultiCountMetric bolt-failed-tuple! 失败 数 牛 
execute-count MultiCountMetric bolt-execute-tuple! HITA E 
execute-latency MultiReducedMetric bolt-execute-tuple! 执行 时 延 
emit-count MultiCountMetric emitted-tuple! 发 送 数 
transfer-count MultiCountMetric transferred-tuple! 传输 数 E 


处 理 时 延 ( process-latency ) 表示 为 从 收 到 该 消息 到 对 该 消息 进行 Ack 操 作 之 间 的 时 间 ， 而 
执行 时 延 (execute-latency ) 指 的 是 调用 Bolt 的 execute 方 法 的 执行 时 间 。 


14.3 ”统计 触发 消息 


在 创建 Executor 时 ，Storm 会 调用 setup-ticks! 方 法 为 该 Executor 设 置 用 于 发 送 触 发 统计 消息 
的 计时 器 ， 其 作用 为 以 固定 的 时 间 间 隔 向 特定 的 流 发 送 消 息 。Executor 在 收 到 该 消息 后 ， 就 会 将 
运行 统计 信息 发 送出 去 然后 将 其 清空 。 触 发 统计 消息 并 不 会 真正 地 从 Executor 中 发 送出 去 ， 且 只 


= 
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有 Executor 自 身 可 以 接收 到 它 ， 其 作用 在 于 提示 Executor 定 期 执行 一 些 Task。 相 关 代 码 如 下 : 


(setup-ticks! worker executor-data) 


14.3.1 注册 统计 信息 


本 节 讨 论 Storm 是 如 何 创建 这 些 统计 信息 并 将 它们 注册 到 系统 中 的 。 
1. 内 置 统计 的 注册 方法 
TopologyContext 对 象 含 有 如 下 两 个 成 员 变 量 : 


private Map«Integer,Map«Integer, Map«String, IMetric>>> registeredMetrics; 
private clojure.lang.Atom  openOrPrepareWasCalled; 


口 _registeredMetrics 用 来 存储 所 有 的 注册 统计 类 别 。 它 的 键 为 统计 时 间 间 隔 ， 由 参数 
TOPOLOGY_BUILTIN_METRICS_BUCKET_SIZE_SECS 设 定 。 其 值 为 另外 一 个 哈 希 表 , 键 为 TaskId， 
该 哈 希 表 的 值 也 为 一 个 哈 希 表 ， 其 键 为 COlobalSstreamId， 值 为 对 应 的 IMetrics。 这 个 
IMetrics 用 来 保存 在 某 一 个 统计 时 间 间 隔 里 某 个 Task 上 某 个 流 的 统计 信息 。 

_registeredMetrics 变 量 对 应 于 Executor 的 数据 interval->task->metric-registry， 且 由 

Executor 创 建 ， 故 一 个 Executor 内 部 的 所 有 Task 将 共享 该 变量 。 

口 _open0rPrepareWasCalled 变 量 表示 Bolt 的 prepare 或 者 Spout 的 open 方 法 是 否 已 经 被 调用 。 
registerMetric 方 法 只 能 在 prepare 或 者 open 方 法 之 中 或 之 前 调用 。 

TopologyContext 对 象 的 registerMetric 方 法 的 代码 如 下 ， 其 中 形 参 name 为 统计 的 名 字 ， 

timeBucketSizeInSecs 表 示 统 计 的 间隔 : 


public «T extends IMetric» T registerMetric(String name, T metric, int timeBucketSizeInSecs) { 
if((Boolean) openOrPrepareWasCalled.deref() -- true) { 
throw new RuntimeException("TopologyContext.registerMetric can only be called from within 


overridden " « 
"IBolt::prepare() or ISpout::open() method."); 


} 


Map m1 = _registeredMetrics; 
if(!m1.containsKey(timeBucketSizeInSecs)) { 
m1.put(timeBucketSizeInSecs, new HashMap()); 


} 


Map m2 = (Map)m1.get(timeBucketSizeInSecs) ; 

if(!m2.containsKey(_taskId)) { 
m2.put(_taskId, new HashMap()); 

} 


Map m3 = (Map)m2.get( taskId); 
if(m3.containsKey(name)) { 
throw new RuntimeException("The same metric name ^" + name + " was registered twice." ); 
) else { 
m3.put(name, metric); 
} 
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return metric; 


} 
2. 创建 并 注册 统计 信息 
在 与 Task 对 应 的 mk-task-data 函 数 中 ,会 调用 make-data 函 数 来 创建 内 置 的 统计 信息 ， 这 些 统 
EAA EAL P Tasai P RIbui Itin- metrics $E, 
XE, make-data KAH FARES ACRI 13 SAK Bl ES Spout Bolt X M7 AVIS FT SEITE FI) 
对 象 ， 其 代码 如 下 : 


(defn make-data [executor-type] 
(condp = executor-type 
:spout (BuiltinSpoutMetrics. (MultiCountMetric.) 
(MultiReducedMetric. (MeanReducer.)) 
(MultiCountMetric.) 
(MultiCountMetric.) 
(MultiCountMetric.)) 

:bolt (BuiltinBoltMetrics. (MultiCountMetric.) 
(MultiReducedMetric. (MeanReducer.)) 
(MultiCountMetric.) 
(MultiCountMetric.) 
(MultiReducedMetric. (MeanReducer.)) 
(MultiCountMetric.) 
(MultiCountMetric.)))) 


之 后 ，Executor 会 在 创建 消息 循环 线程 时 ， 将 这 些 统计 信息 注册 到 TopologyContext 对 象 中 ， 
相关 代码 如 下 : 
(builtin-metrics/register-all (:builtin-metrics task-data) storm-conf (:user-context task-data)) 


register-al] 方 法 的 形 参 :builtin-metrics 为 通过 make-data 函 数 创 建 的 统计 集合 ， 其 代码 如 下 : 


(defn register-all [builtin-metrics storm-conf topology-context] 
(doseq [[kw imetric] builtin-metrics] 
(.registerMetric topology-context (str " ^" (name kw)) imetric 
(int (get storm-conf Config/TOPOLOGY BUILTIN METRICS BUCKET SIZE SECS))))) 


可 以 看 出 ， 内 置 统计 的 名 字 是 以 “ ”作为 前 缀 的 。 目 前 ，Storm 中 只 有 一 种 统计 的 时 间 间 
隔 设 置 项 TopOLOGY BUILTIN METRICS BUCKET SIZE SECS, 其 默认 值 为 60 秒 。 


14.3.2 ”触发 消息 的 产生 与 发 送 


setup-metrics! PAU D EET ES, 该 计时 咒 将 定期 地 向 _tick 流 发 送 消息 。 当 Task 收 到 这 
些 消息 后 , 统计 信息 就 会 被 发 送出 去 , 于 是 系统 中 的 统计 节点 便 可 以 收 到 这 些 统计 信息 。 该 函数 
的 实现 如 下 : 


" 


1 (defn setup-metrics! [executor-data] 
2 (let [{:keys [storm-conf receive-queue worker-context interval->task->metric-registry]} 
executor-data 
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3 distinct-time-bucket-intervals (keys interval->task->metric-registry)] 

4 (doseq [interval distinct-time-bucket-intervals] 

5 (schedule-recurring 

6 (:user-timer (:worker executor-data)) 

7 interval 

8 interval 

9 (fn [] 

10 (disruptor/publish 

11 receive-queue 

12 [[nil (TuplelImpl. worker-context [interval] Constants/SYSTEM TASK ID 


Constants/METRICS TICK STREAM ID)]])))))) 


a 第 3 行 获得 统计 间隔 的 个 数 ， 目 前 只 有 一 个 ， 间 隔 的 大 小 为 60 秒 。 

口 第 5 行 设置 一 个 计时 器 ， 其 时 间 间 隔 为 统计 的 时 间 间 隔 。 

口 回调 函数 的 实现 。 该 函数 将 向 Executor 的 接收 消息 队列 发 送 一 条 消 
息 ， 这 个 消息 的 TaskId 为 nil1， 表 明 该 Executor 所 包含 的 Task 都 要 执行 该 消息 。 消 息 的 内 容 
SEM. 该 消息 会 被 发 送 至 流 _ tick。 


14.3.3 ”处 理 统计 触发 消息 


当 Executor 收 到 来 自 on 将 调用 metrics-tick 函 数 来 准备 和 发 送 统 计 消 息 , 其 
中 统计 消息 中 含有 该 节点 的 运行 统计 结果 。metrics-tick 国 数 的 实现 如 下 : 


1 (defn metrics-tick [executor-data task-datas ^TupleImpl tuple] 


2 (let [{:keys [interval-»task-»metric-regiretry ^WorkerTopologyContext worker-context]] 
executor-data 

3 interval (.getInteger tuple 0)] 

4 (doseq [[task-id task-data] task-datas 

5 :let [name-»imetric (-» interval->task->metric-registry (get interval) (get 

task-id)) 

6 task-info (IMetricsConsumer$TaskInfo. 

7 (. (java.net.InetAddress/getLocalHost) getCanonicalHostName) 

8 (.getThisWorkerPort worker-context) 

9 (:component-id executor-data) 

10 task-id 

11 (long (/ (System/currentTimeMillis) 1000)) 

12 interval) 

13 data-points (-»» name-»imetric 

14 (map (fn [[name imetric]] 

15 (let [value (.getValueAndReset ^IMetric imetric)] 

16 (if value 

17 (IMetricsConsumer$DataPoint. name value))))) 

18 (filter identity) 

19 (into []))]] 

20 (if (seq data-points) 

21 (task/send-unanchored task-data Constants/METRICS STREAM ID [task-info data-points]))))) 


O 在 Executor 中 ， 关 键 字 interval->task->metric-regiretry 存 储 着 日 前 的 运行 统计 ， 第 3 行 
获取 消息 的 内 容 ， 即 将 获得 的 统计 时 间 间 隔 存 储 到 interval 变 量 。 


qu 
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口 第 4 行 遍 历 Task 的 数据 task-datas，Executor 所 包含 的 每 一 个 Task 都 将 被 进行 这 一 处 理 。 

O 第 5 行 中 name->imetric 为 该 统计 间隔 interval 以 及 该 task-id 对 应 的 统计 信息 。 

口 第 6~12 行 用 于 构建 task-info 对 象 。 该 对 象 包含 该 Task 的 主机 名 、Worker 的 端口 号 、 组 件 、 

taskId、 当 前 时 间 以 及 统计 间隔 。 

口 第 13~19 行 用 于 构建 data-points。 这 里 会 对 name->imetric 中 的 每 一 条 记录 调用 getValue- 
AndReset 函 数 ,， 以 获得 记录 的 当前 值 并 清空 ,然后 过 滤 掉 其 中 的 空 类 型 元 素 并 将 结果 存储 
到 数组 中 。 

口 在 第 20~21 行 中 ， 和 在 data-points 不 为 空 ， 则 发 送 消 息 [task-info ，data-points] 到 流 
METRICS STREAM ID 中 。 
当 一 个 Executor 中 存在 多 个 Task 时 ， 该 方法 是 存在 一 定 问 题 的 。 由 于 处 理 一 条 统计 触发 消息 

时 ，Executor 中 所 有 的 Task ( 而 非特 定 的 Task ) 都 会 执行 一 次 , 并 且 每 次 执行 过 程 中 , 所 有 的 Task 

均 会 被 再 次 执行 ， 因 此 第 一 次 执行 时 将 所 有 Task 的 统计 值 设置 为 0， 再 次 执行 时 ， 则 会 将 统计 值 0 

作为 消息 内 容 发 送出 去 。 例 如 , Executor 中 含有 两 个 Task, 收 到 一 条 统计 触发 消息 时 , metrics-tick 

函数 将 被 执行 两 次 。 然 而 ， 每 次 执行 时 ， 第 4 行 又 对 每 一 个 Task 进 行 执行 ， 故 将 产生 问题 。 


14.4 ”运行 统计 收集 节点 


Storm 会 根据 配置 文件 中 TOPOLOGY-METRICS-CONSUMER-REGISTER 的 设置 来 创建 运行 统计 的 收集 
节点 。metitics-consumer-bolt-specs 函 数 用 来 创建 需要 的 这 些 节 点 ， 相 关 代 码 如 下 : 


1 (defn metrics-consumer-bolt-specs [components-ids-that-emit-metrics storm-conf] 
2 (let [inputs (-»» (for [comp-id components-ids-that-emit-metrics] 

3 ([comp-id METRICS-STREAM-ID] :shuffle]) 

4 (into {})) 

5 

6 mk-bolt-spec (fn [class arg p] 

7 (thrift/mk-bolt-spec* 

8 inputs 

9 (backtype.storm.metric.MetricsConsumerBolt. class arg) 
10 {} :p p :conf {TOPOLOGY-TASKS p}))] 

11 

12 (map 

13 (fn [component-id register] 

14 [component-id (mk-bolt-spec (get register "class") 

15 (get register "argument") 

16 (or (get register "parallelism.hint") 1))]) 

17 

18 (metrics-consumer-register-ids storm-conf) 


19 (get storm-conf TOPOLOGY-METRICS-CONSUMER-REGISTER)))) 


O 第 2~4 行 获得 所 有 组 件 的 METRICS-STREAM-ID 流 ， 并 设置 为 Shuffle 分 组 方式 ， 然 后 将 它们 存 
储 到 变量 inputs 中 。 这 为 创建 统计 收集 节点 做 准备 , 任何 一 个 统计 收集 节点 都 需要 收听 所 
有 节点 的 METRICS-STREAM-ID 流 。 
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O 第 6~10 行 定义 了 一 个 函数 mk-bolt-spec， 它 利用 thrift/mk-bolt-spec*x 函 数 创 建 了 一 个 
Bolt 节 点 。 这 里 inputs 为 输入 流 集合 ，class 和 arg 为 构建 Bolt 所 需要 依据 的 参数 ， 节 点 类 
型 为 MetricsConsumerBolt。 设 置 并 行 度 为 p， 默 认 值 为 0， 表 示 该 节点 并 没有 放 和 Storm 系 
No 这 也 是 内 置 的 运行 统计 没有 在 Storm 中 开启 的 原因 之 一 。 

第 13~16 行 的 函数 将 遍历 第 18 行 和 第 19 行 的 集合 ， 其 中 mk-bolt-spec 函 数 用 来 定义 一 个 组 
EA 例如 ， 系 统 中 注册 了 两 个 相同 的 Metrics 类 MyMetricsConsumer ， 则 第 一 个 的 名 字 为 


. metrics org.mycompany.MyMetricsConsumer, 第 二 个 的 名 字 为 _metrics org.mycompany. 


MyMetricsConsumer#2。 感 兴趣 的 读者 可 以 阅读 metrics-consumer-register-ids、number- 
duplicates 以 及 map-occurrences 函 数 ， 学 习 该 名 字 是 如 何 计 算得 到 的 。 
a 第 18 行 利用 metrics-consumer-register-ids 函 数 为 注册 的 统计 收集 节点 命名 , 该 函数 返回 
一 个 集合 。 
口 第 19 行 获得 注册 的 统计 节点 集合 。 
下 面 简要 介绍 这 些 系 统 节 点 是 如 何 蔡 入 在 Storm 的 Topology 中 的 。 
add-metric-components! 函数 会 调用 metrics-consumer-bolt-specs 困 数 ,并 将 得 到 的 Bolt 添 加 
到 Topology 中 ， 其 代码 如 下 : 


(defn add-metric-components! [storm-conf ^StormTopology topology] 
(doseq [[comp-id bolt-spec] (metrics-consumer-bolt-specs (keys (all-components topology)) 
storm-conf)] 
(.put to bolts topology comp-id bolt-spec))) 

在 生成 Worker 对 应 数据 的 XE 中 ， E 始 化 :task->component 关 键 字 所 对 应 的 值 时 ， 将 调用 
storm-task-info 函 数 未 对 该 变量 赋值 , 变量 : task->component 中 含有 从 taskId 到 组 件 的 映射 关系 。 

storm-task-info [PK 数 将 在 有 JH P1 xi SCY Topology AY A& fili E Yl FA system-topology! K 2a, Jy 
Topology 添 加 一 些 系 统 Bolt 以 协助 系统 工作 。 例 如 ， 本 章 所 讨论 的 统计 收集 节点 就 是 通过 add- 
metric-components1 函 数 来 添加 的 。storm-task-info 函 数 的 代码 如 下 : 


(defn storm-task-info 

"Returns map from task -> component id" 

[^StormTopology user-topology storm-conf] 

(-»» (system-topology! storm-conf user-topology) 
all-components 
(map-val (comp #(get % TOPOLOGY-TASKS) component-conf)) 
(sort-by first) 
(mapcat (fn [[c num-tasks]] (repeat num-tasks c))) 
(map (fn [id comp] [id comp]) (iterate (comp int inc) (int 1))) 
(into {}) 
)) 


sytem-topology! 孙 数 用 于 添加 系统 节点 以 同系 统 提供 支持 ,该 函数 的 定义 如 下 ， 其 中 
add-metric-components! 函 数 用 来 添加 统计 信息 收集 节点 : 


(defn system-topology! [storm-conf ^StormTopology topology] 
(validate-basic! topology) 
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(let [ret (.deepCopy topology)] 
(add-acker! storm-conf ret) 
(add-metric-components! storm-conf ret) 
(add-metric-streams! ret) 
(add-system-streams! ret) 
(add-system-components! ret) 
(validate-structure! ret) 
ret 


) 
add-metric-streams! 函数 用 于 将 统计 流 作 为 系统 中 每 一 个 节点 的 输出 流 。 于 是 ， 用 户 定义 
c nU M ， 其 输出 模式 为 [ "task-info" 
"data-points"]。 该 函数 的 实现 如 下 : 


(defn add-metric-streams! [^StormTopology topology] 
(doseq [[_ component] (all-components topology) 
:let [common (.get common component)]] 
(.put to streams common METRICS-STREAM-ID 
ee oo. "data-points"])))) 


MetTricsConsumerBolt 将 接受 这 些 运 行 统计 信息 。MetricsConsumerBolt 类 将 接收 一 个 实现 了 
IMetricsConsumer 的 类 作为 参数 ， de 的 一 个 对 象 ， 在 execute 函 数 中 调用 
该 类 的 handleDatapPoints 玉 数 ， 该 函数 的 输入 为 TaskInfo 以 及 Datapoints。 相 关 代 码 如 下 : 


@Override 
public void prepare(Map stormConf, TopologyContext context, OutputCollector collector) { 
try { 
_metricsConsumer = (IMetricsConsumer)Class.forName( consumerClassName).newInstance(); 
} catch (Exception e) { 
throw new RuntimeException("Could not instantiate a class listed in config under section" + 
Config. TOPOLOGY METRICS CONSUMER REGISTER + " with fully qualified name " + 
_consumerClassName, e); 


】 
_metricsConsumer.prepare(stormConf, registrationArgument, context, (IErrorReporter) 
collector); 
collector - collector; 
} 
@Override 


public void execute(Tuple input) { 
 metricsConsumer.handleDataPoints((IMetricsConsumer.TaskInfo)input.getValue(0), (Collection) 
input.getValue(1)); 
_collector.ack(input) ; 


14.5 SystemBolt 


SystemBolt 是 系统 中 的 一 种 特殊 Bolt, 每 个 Worker 都 会 启动 一 个 这 样 的 Bolt。 它 的 TaskId 为 -1 , 
因此 不 会 有 用 户 消息 发 送 至 该 Bolt， 但 它 会 接收 统计 信息 触发 消息 。 
该 Bolt 会 注册 一 些 自 定义 的 统计 信息 ， 并 在 收 到 流 METRICS_TICK_STREAM_ID 中 的 消息 后 
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调用 该 Task 所 对 应 的 metrics-tick 方 法 。 于 是 ， 


这 些 统计 信 ， 


息 便 被 发 送 了 出 去 并 且 重 置 ， 而 达 


到 了 Worker 所 在 进程 的 统计 信息 则 会 被 发 送 到 运行 统计 收集 节点 上 去 。 该 Bolt 注 册 的 统计 信息 


如 表 14-3 所 示 。 


表 14-3 SystemBolt 中 含有 的 运行 统计 


统计 信息 fa xk 
MenoryUsageMetric 获得 该 进程 的 内 存 使 用 情况 ， 主 要 有 如 下 统计 : 
口 maxBytes 
口 committed 
口 initBytes 
口 usedBytes 
口 virtualFreeBytes 
口 unusedBytes 
在 有 具体 实现 中 ， 该 统计 通过 调用 MemoryMXBean 的 方法 获得 
GarbageCollectorMetric 进程 垃圾 回收 情况 ,含有 如 下 统计 : 
口 Count 
口 timeMs 
在 具体 实现 中 ， 该 统计 通过 调用 GarbageCollectorMXBean 的 方法 获得 
uptimeSecs 启动 时 间 。 
在 具体 实现 中 ， 该 统计 通过 调用 RuntimeMXBean.getUptime() 方 法 获得 
startTimeSecs RuntimeMXBean.getStartTime() 
newWorkerEvent 首次 创建 Worker 时 为 1 
memory/heap RuntimeMXBean. getHeapMemoryUsage 
memory/nonHeap RuntimeMXBean.getNonHeapMemoryUsage 


读者 可 以 参考 MemoryUsageMetric 和 GarbageCollectorMetric 的 类 实现 来 学 习 如 何 实现 用 户 自 


定义 统计 。 


2E fU Hi, add-system-components! PA 2 n] 4% SystemBolt Zs jill $l| Worker , EH] LA S£ system- 


topology! PAH, HEXIA P: 


(defn add-system-components! [conf ^StormTopology topology] 


(let [system-bolt-spec (thrift/mk-bolt-spec* 


{} 
(SystemBolt.) 


(SYSTEM-TICK-STREAM-ID (thrift/output-fields ["rate secs"]) 
METRICS-TICK-STREAM-ID (thrift/output-fields ["interval"])] 


:p 0 
:conf (TOPOLOGY-TASKS 0))] 


(.put to bolts topology SYSTEM-COMPONENT-ID system-bolt-spec))) 


可 以 看 出 ， 该 Bolt 只 接收 SYSTEM-TICK-STREAM 以 及 METRICS-TICK-STREAM。 


事务 Topology 的 实现 


事务 类 型 的 Topology 是 Storm 中 的 关键 实现 之 一 ， 在 处 理 消息 的 过 程 中 ， 它 将 保证 消息 不 会 

被 丢失 。 如 果 再 结合 具有 去 重 功能 的 存储 ， 就 可 以 实现 消息 被 整个 系统 处 理 一 次 且 仅 处 理 一 次 。 
Storm 项 目的 作者 Nathan 在 下 面 的 链接 中 提 到 了 一 些 有 关 事务 Topology 的 关键 概念 : 

https://github.com/nathanmarz/storm/wiki/Transactional-topologies。 人 徐 明 明 翻 译 了 这 篇 文章 并 给 出 了 

一 些 个 人 见解 ， 相 关 链 接 为 http://xumingming.sinaapp.com /736/twitter-storm-transactional-topolgoy/。 
本 章 将 对 事务 类 型 的 Topology 的 实现 进行 系统 的 分 析 。 


15.1 事务 Topology 的 实现 概述 


事务 Topology 的 实现 概述 如 下 。 

口 事务 类 型 的 Spout 节 点 实际 上 是 一 个 子 Topology, 它 包含 一 个 协调 Spout 节 点 (Coordinator ) 

以 及 一 些 消 息 发 送 Bolt 节 点 ( Emitter )。 

口 协调 Spout 节 点 的 并 行 度 为 1， 消 息 发 送 Bolt 节 点 的 并 行 度 则 可 根据 需要 来 设 定 。 

口 协调 Spout 节 点 并 不 发 送 实 际 的 数据 ， 而 是 将 事务 尝试 发 送 到 消息 将 Bolt 节 点 中 。 事 务 尝 
iX ( TransactionalAttempt ) 包含 一 个 BigInteger 类 型 的 事务 号 以 及 长 整 型 类 型 的 尝试 号 。 
当 事 务 被 重 传 时 ， 事务 号 是 相同 的 ， 但 是 尝试 号 不 同 。 

口 协调 Spout 节 点 与 消息 发 送 Bolt 节 点 之 间 采 用 全 局 分 组 方式 进行 消息 传输 ， 也 就 意味 着 从 
协调 Spout 中 发 送 的 一 条 事务 尝试 消息 都 会 被 所 有 的 消息 发 送 Bolt 节 点 接收 。 每 个 消息 发 
送 Bolt 节 点 会 根据 收 到 的 事务 尝试 消息 来 发 送 与 该 事务 对 应 的 消息 集合 。 消 息 发 送 Bolt 节 
点 之 间 则 需要 对 该 事务 所 对 应 的 数据 进行 协作 ， 即 每 个 节点 只 负责 事务 的 一 部 分 数据 。 

口 当 所 有 的 消息 发 送 节 点 都 成 功 处 理 了 该 事务 在 该 节点 上 所 对 应 的 消息 后 〈 通 过 Storm 的 
Ack 框 架 ), 协调 Spout 节 点 认为 该 事务 已 经 被 成 功 处 理 , 协调 SpoutT 点 将 会 产生 并 发 送 下 
一 个 事务 尝试 消息 。 

口 协调 Spout 节 点 中 含有 两 个 系统 输出 流 : 事务 消息 流 (Batch 流 ) 和 事务 提交 流 ( Commit 流 ) 

协调 Spout 节 点 会 向 事务 消息 流 发 送 事务 尝试 消息 ， 向 事务 提交 流 发 送 事务 的 提交 消息 。 

口 事务 的 人 处理 实际 上 被 分 成 以 下 两 个 阶段 。 

m 事务 处 理 阶 段 : 协调 Spout 节 点 向 消息 发 送 节 点 发 送 事 务 尝试 消息 ， 消 息 发 送 Bolt 节 点 
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发 送 该 事务 所 对 应 的 消息 集合 ， 然 后 Storm 系 统 开 始 处 理 这 些 消 息 。 该 阶段 属于 事务 的 
处 理 阶 段 。 

m 事务 提交 阶段 : 通过 系统 的 Ack 框 架 ， 当 系统 中 的 消息 均 被 成 功 处 理 后 ， 协 调 Spout 节 
点 将 收 到 其 发 送 的 事务 尝试 消息 的 Ack， 这 表明 事务 处 理 阶 段 已 经 结束 。 

在 事务 类 型 的 Topology 中 , 可 以 定义 事务 提交 Bolt ( Commit Bolt )， 这 种 类 型 的 Bolt 节 点 可 保 
证 其 处 理 的 事务 会 按照 顺序 被 提交 。 事 务 的 提交 操作 可 能 是 将 事务 的 处 理 结果 存储 起 来 。 

在 Storm 中 ， 若 消息 丢失 或 者 超时 ， 一 个 事务 可 能 会 被 重 做 ， 此 时 将 导致 消息 重复 。 但 由 于 提 
交 节 点 可 以 保证 事务 是 按照 顺序 提交 的 ,此 处 更 利于 去 重 操作 。 例 如 , 若 每 个 事务 对 应 的 数据 在 重 
传 时 相同 ， 则 在 提交 节点 看 到 相同 的 事务 序号 时 ， 可 认为 该 事务 是 重 传 的 事务 ， 进 而 将 其 忽略 掉 。 

当 事 务 的 处 理 阶段 完成 后 ， 协 调 Spout 节 点 会 检查 该 事务 是 否 为 下 一 个 要 提交 的 事务 ， 若 是 
则 将 该 事务 的 事务 序号 发 送 到 事务 提交 流 。 所 有 的 事务 提交 Bolt 节 点 都 会 接收 该 流 的 消息 ， 并 会 
在 收 到 事务 提交 消息 后 ， 对 该 事务 进行 提交 。 可 以 看 出 ， 当 事务 处 理 阶 段 结束 后 ， 并 不 一 定 会 立 
即 进 入 事务 提交 阶段 , 它 需 要 等 待 之 前 的 事务 都 已 经 被 成 功 提交 后 , 方 可 进入 事务 提交 阶段 。 此 
处 ,保证 了 事务 按 顺 序 提交 。 
通过 系统 的 Ack 框 架 ， 在 收 到 事务 提交 消息 的 Ack 之 后 ， 该 事务 被 认为 已 成 功 处 理 。 

在 事务 提交 节点 , 将 调用 节点 的 finishBatch 方 法 完成 事务 的 提交 。 其 他 的 处 理 节 点 ( BatchBolt ) 
同样 含有 finishBatch 回 调 方 法 , 但 它 却 表示 在 该 节点 上 所 有 属于 同一 事务 的 消息 都 已 经 被 处 理 。 本 
章 将 在 CoordinatedBolt 类 的 实现 中 详细 讨论 Storm 是 如 何 保证 finishBatch 方 法 被 正确 调用 的 。 

在 事务 处 理 阶 段 ， 属 于 一 个 事务 的 消息 以 及 所 有 衍生 出 来 的 消息 均 以 协调 Spout 节 点 发 送 的 
事务 尝试 消息 为 根 。 基 于 Storm 的 Ack 框 架 ， 当 所 有 的 消息 均 被 成 功 处 理 之 后 ， 协 调 Spout 节 点 将 
收 到 一 条 事务 尝试 消息 的 Ack。 若 消息 处 理 失 败 或 者 超时 ,协调 $Spout 节 点 则 会 收 到 失败 消息 , 事 
务 类 型 的 Topology 此 时 会 对 该 事务 进行 重 传 处 理 。 这 样 ， 事 务 类 型 的 Topology 便 可 以 保证 消息 不 
ER, KRE, 事务 尝试 消息 会 存储 于 ZooKeeper 中 ， 所 以 即便 Topology 异 常 停止 运行 ， 仍 可 保 
证 在 其 重新 启动 时 事务 能 被 正确 重 传 。 

根据 其 中 Spout 类 型 的 不 同 ， 事 务 Topology 可 被 进一步 分 为 基本 事务 Topology 和 模糊 事务 
Topology ( Opaque Transactional Topology )， 接 下 来 详细 讨论 一 下 。 


15.1.1 事务 Topology 的 类 型 


根据 Topology 中 Spout 类 型 的 不 同 ，Topology 可 以 分 为 如 下 两 种 类 型 。 

口 韭 事 务 Topology( Non-Transactional ): Spout 的 类 型 为 IRichspout。Storm 并 不 保证 消息 的 

可 靠 传输 ， 故 消息 可 能 会 丢失 。 

口 事务 Topology: Spout 的 类 型 为 ITransactionalSpout。 此 时 ，Storm 负 责 初始 化 一 个 事务 ， 
并 负责 在 事务 失败 时 对 其 进行 重 传 。 事 务 Topology 保 证 了 消息 的 可 靠 传输 , 以 及 在 事务 提 
交 节 点 处 ,事务 按 顺序 被 提交 。 根 据 对 ITransactionalSpout 接 口 的 不 同 实现 ,事务 Topology 
可 以 进一步 分 为 两 种 类 型 。 

m 基本 事务 Topology: 每 个 事务 所 对 应 的 数据 在 事务 被 重 传 时 不 发 生变 化 。 用户 只 要 保证 
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数据 的 元 数据 不 变 ， 就 可 每 次 获取 到 相同 的 数据 集合 。 例 如 ，Spout 的 数据 源 为 一 个 大 
的 数据 文件 ， 每 个 事务 负责 读 取 数 据 文件 的 一 部 分 。 这 时 ， 可 以 将 事务 的 元 数据 设计 
为 某 部 分 数据 在 数据 文件 中 的 位 移 量 及 数量 。 于 是 ， 当 事务 被 重 传 时 ， 根 据 该 元 数据 ， 
事务 所 对 应 的 数据 不 会 发 生变 化 ， 这 就 满足 了 基本 事务 Topology 所 需 的 前 提 条 件 。 
m 模糊 事务 Topology: 每 个 事务 所 对 应 的 数据 在 事务 重 传 时 可 能 发 生变 化 , 但 会 保证 事务 
中 的 消息 只 属于 某 一 个 事务 , 即 保 证 同一 条 消息 不 会 同时 属于 多 个 事务 。 例如 , 在 Spout 
从 Kafka 队 列 读 取 数据 时 ， 事务 的 元 数据 可 以 为 Kafka 队 列 中 的 位 移 量 ; 当 事 务 重 传 时 ， 
Kafka 队 列 中 可 能 已 经 含有 了 新 的 数据 ， 于 是 被 重 传 的 事务 可 以 将 这 些 新 消息 包含 在 其 
中 。 此 时 ， 重 传 事务 与 原始 事务 所 对 应 的 消息 不 同 ， 但 每 条 消息 却 只 属于 同一 个 事务 ， 
故 满足 了 模糊 事务 Topology 的 前 提 条 件 。 
不 同事 务 类 型 的 Topology 对 应 于 不 同 的 去 重 办 法 。 对 于 基本 事务 Topology， 结 果 集 合 只 需要 
存储 事务 序号 以 及 相应 的 事务 处 理 结果 即 可 。 若 收 到 相同 的 事务 序号 时 ， 只 需要 将 数据 丢弃 ; 而 
在 收 到 不 同 的 事务 序号 时 ， 才 对 数据 进行 更 新 。 对 于 模糊 事务 Topology， 仅 仅 保存 当前 的 事务 序 
号 并 不 足够 , 因为 即便 事务 序号 相同 ， 其 对 应 的 数据 也 可 能 不 同 ， ee 
前 所 对 应 的 数据 。 在 第 19 章 中 ， 我 们 会 对 事务 数据 的 去 重 进 行 较为 详细 的 介 
此 外 ,根据 ITransactionalSpout 的 具体 实现 ， E 
Topology 以 及 非 分 区 的 事务 Topology。 对 于 分 区 的 事务 Topology， 每 个 发 送 节 点 只 负责 特定 的 数 
据 分 区 ， 它 更 适用 于 读 取 Kafka 队列 。 


15.1.2 ”事务 Topology 的 类 关系 
事务 Topology 的 类 关系 如 图 15-1 所 示 。 
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图 15-1 事务 Topology 的 类 关系 


通过 表 15-1 ， 我 们 可 以 初步 了 解 这 些 类 和 接口 。 学 习 这 些 类 的 实现 是 理解 事务 类 型 的 
Topology 的 关键 。 
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表 15-1 事务 Topology 的 接口 以 及 实现 类 


接口 或 者 类 描 述 

ITransactionalSpout 基本 事务 Topology 的 Spout 接 口 ， 内 含 两 部 分 接口 : 协调 Spout 接 口 以 
及 消息 发 送 Bolt 接 口 

TransactionalSpoutBatchExecutor Bolt 类 型 ， 用 于 执行 ITransactionalSpout 中 的 消息 发 送 Bolt 节 点 

TransactionalSpoutCoordinator Spout 类 型 ， 用 于 执行 ITransactionalSpout 中 的 协调 Spout 节 点 ,是 系统 
中 唯一 的 Spout 三 点 ,具体 功能 为 初始 化 事务 以 及 产生 事务 尝试 消息 等 

IPartitionedTransactionalSpout 分 区 的 事务 Topology 的 Spout 接 口 ， 用 户 通过 该 接口 来 完成 Spout 的 分 
区 功能 

PartitionedTransactionalSpoutExecutor 为 ITransactionalSpout 类 型 ， 主 要 用 于 适 配 IPartitionedTransactional 
Spout 接 口 ， 为 IPartitionedTransactionalSpout 的 执行 器 

IOpaquePartitionedTransactionalSpout 分 区 的 模糊 事务 Topology 的 Spout 接 口 , 用 户 通过 该 接口 来 完成 模糊 事 
务 类 型 的 Topology 

OpaquePartitionedTransactionalSpoutExecutor ^ 为 ITransactionalSpout 类 型 , 用 于 适 配 IOpaquePartitionedTransactional 


Spout 接 口 ， uv i 执行 器 


ICommitterTransactionalSpout 具有 提交 功能 的 事务 Topology 的 Spout 接 口 ， 主 要 用 于 模糊 事务 
dip urs Se 点 


15.2 ITransactionalSpout 接口 


ITransactionalSpout 接 口中 包含 两 部 分 接口 ， 一 部 分 接口 用 于 提供 协调 Spout 节 点 的 逻辑 ， 
一 部 分 接口 用 于 提供 消息 发 送 BoltT 点 的 逻辑 。 用 户 只 需要 实现 这 些 接口 , Storm 便 会 负责 将 这 些 
逻辑 部 署 到 合适 的 节点 上 和 运行。 仔细 阅读 接口 的 注释 对 于 了 解 如 何 使 用 该 接口 很 有 帮助 。 该 接口 
的 定义 如 下 : 


public interface ITransactionalSpout<T> extends IComponent { 
public interface Coordinator«X» { 
/** 
* Create metadata for this particular transaction id which has never 
* been emitted before. The metadata should contain whatever is necessary 
to be able to replay the exact batch for the transaction at a later point. 


The metadata is stored in Zookeeper. 


* 
* 
* 
* 
* Storm uses the Kryo serializations configured in the component configuration 
* for this spout to serialize and deserialize the metadata. 

* 

* @param txid The id of the transaction. 

* (param prevMetadata The metadata of the previous transaction 

* @return the metadata for this new transaction 

xf 

X initializeTransaction(BigInteger txid, X prevMetadata); 


[** 
* Returns true if its ok to emit start a new transaction, false otherwise (will skip this 
* transaction). 
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* You should sleep here if you want a delay between asking for the next transaction (this will 
* be called repeatedly in a loop). 

*/ 

boolean isReady(); 


/** 
* Release any resources from this coordinator. 
*/ 

void close(); 


} 
public interface Emitter«X» { 
/** 
* Emit a batch for the specified transaction attempt and metadata for the transaction. The 
* metadata was created by the Coordinator in the initializeTranaction method. This method must 
always emit the same batch of tuples across all tasks for the same transaction id. 
* 
* The first field of all emitted tuples must contain the provided TransactionAttempt. 
* 
*/ 
void emitBatch(TransactionAttempt tx, X coordinatorMeta, BatchOutputCollector collector); 
/** 
* Any state for transactions prior to the provided transaction id can be safely cleaned up, 
* so this method should clean up that state. 
2y 
void cleanupBefore(BigInteger txid); 
/** 
* Release any resources held by this emitter. 
iu 
void close(); 
} 
/** 


* The coordinator for a TransactionalSpout runs in a single thread and indicates when batches 
* of tuples should be emitted and when transactions should commit. The Coordinator that you provide 
* in a TransactionalSpout provides metadata for each transaction so that the transactions can be 
* replayed. 
id 
Coordinator«T» getCoordinator(Map conf, TopologyContext context); 
/** 
* The emitter for a TransactionalSpout runs as many tasks across the cluster. Emitters are responsible 
* for emitting batches of tuples for a transaction and must ensure that the same batch of tuplesis 
* always emitted for the same transaction id. 
*/ 
Emitter<T> getEmitter(Map conf, TopologyContext context); 

】 


协调 Spout 节 点 的 isReady 方 法 用 来 检测 当前 是 否 可 以 开始 一 个 新 事务 。 在 Storm 中 , 许多 地 方 
都 可 能 是 产生 新 事务 的 合适 时 间 点 。 例 如 , 在 Spout 收 到 Ack 消 息 后 ， 上 一 个 事务 可 能 已 经 处 理 结 
WR, 此 时 可 以 调用 isReady 方 法 来 判断 是 否 可 以 开始 一 个 新 事务 .类似 地 , 在 Spout 节 点 的 nextTuple 
方法 中 , 也 会 调用 isReady 方 法 来 判断 是 否 可 以 开始 一 个 新 事务 。 从 前 面 对 Executor 的 讨论 可 以 知 
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道 ，Spout 的 主 循环 线程 会 依次 处 理 输入 消息 以 及 产生 新 的 消息 ， 这 要 求 其 中 调用 的 方法 应 是 非 
阻塞 的 。 因 此 ，isReady 方 法 需要 设计 为 非 阻塞 的 , 也 即 如 果 新 事务 并 不 就 绕 ， 就 立即 返回 false， 
而 不 应 该 调用 Sleep 方 法 。 注 释 中 建议 使 用 睡眠 方法 是 不 正确 的 。 
initializeTransaction 方 法 用 于 产生 新 事务 的 元 数据 , 它 可 以 基于 上 一 个 事务 的 元 数据 来 产 
^E. 在 初始 化 第 一 个 事务 时 ，prevMetadata 为 空 。 注 意 ,该 方法 仅 当 isReady 方 法 返回 true 时 才 有 
可 能 被 调用 到 ， 并 且 对 于 每 个 事务 它 只 会 调用 一 次 。 
在 消息 发 送 Bolt 节 点 的 接口 中 ，emitBatch 方 法 最 为 重要 。 协 调 Spout 市 点 发 送 的 事务 滨 试 消 
息 都 会 到 达 消 息 发 送 Bolt 节 点 ,然后 该 节点 会 调用 emitBatch 方 法 来 发 送 一 批 数 据 。 这 个 过 程 要 保 
证 同一 个 事务 序号 对 应 于 相同 的 数据 (模糊 事 务 类 型 的 Spout 除 外 ) 注意 , 对 于 同一 个 事务 序号 ， 
该 方法 可 能 会 被 调用 多 次 ( 壁 如 事务 被 重 传 时 )。 
cleanupBefore 方 法 只 有 在 与 输入 的 事务 序号 相对 应 的 事务 全 被 成 功 处 理 后 才 会 被 调用 , 它 负 
给 用 户 提供 合适 的 时 间 点 来 清理 与 事务 相关 的 数据 。 


15.3 协调 Spout 节点 的 执行 器 


与 ITransactionalSpout 中 的 协调 Spout 接 口 相 对 应 的 逻辑 需要 放 在 一 个 SpoutT 点 中 来 执行 ， 该 
Spout 节 点 是 系统 中 唯一 真正 的 Spout 节 点 , 它 产生 事务 尝试 消息 并 将 消息 发 送 给 消息 发 送 Bolt 节 点 。 

TransactionalSpoutCoordinator 类 人 负责 产生 并 维护 这 些 事务 尝试 消息 ， 它 会 调用 协调 Spout 
接口 中 用 户 定 义 的 逻辑 ,是 事务 Topology 中 非常 重要 的 部 分 。 理 解 这 个 类 对 于 理解 事务 Topology 
非常 关键 。 

为 了 实现 消息 的 可 靠 重 传 , 所 有 正在 处 理 的 事务 尝试 消息 都 会 被 存储 在 ZooKeeper 里 ，Storm 
提供 了 两 个 工具 类 用 于 维护 这 些 消息 。 本 章 首先 讨论 事务 Topology 对 ZooKeeper 的 使 用 。 


a 


15.3.1 ZooKeeper 客 户 端 工具 


在 事务 Topology 中 ，TransactionalState 类 用 于 存储 事务 的 元 数据 ， 它 是 基于 Curator 
Framework 实 现 的 。Curator Framework 是 Apache 下 面 的 一 个 开源 软件 ， 它 为 更 好 地 使 用 ZooKeeper 
提供 了 支持 ， 详 情 可 访问 http://curator.incubator.apache.org/curator-framework/。 
TransactionalState 类 主要 用 于 维护 ZooKeeper 中 某 一 个 目录 下 面 的 所 有 子 节 点 。 在 事务 Topology 
每 个 正在 处 理 的 事务 都 对 应 该 目录 下 面 的 一 个 节点 。TransactionalState 类 的 实现 如 下 : 


申 


public class TransactionalState { 
CuratorFramework curator; 
KryoValuesSerializer ser; 
KryoValuesDeserializer des; 


public static TransactionalState newUserState(Map conf, String id, Map componentConf) { 


1 
2 
3 
4 
5 
6 
7 return new TransactionalState(conf, id, componentConf, "user"); 
8 } 

9 
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10 


11 
12 
13 
14 
15 
16 
17 


18 
19 
20 
21 
22 
23 


24 


25 


26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 


public static TransactionalState newCoordinatorState(Map conf, String id, Map componentConf) 


{ 
} 


return new TransactionalState(conf, id, componentConf, "coordinator"); 


protected TransactionalState(Map conf, String id, Map componentConf, String subroot) { 
try ( 
conf - new HashMap(conf); 
// ensure that the serialization registrations are consistent with the 
declarations in this spout 
if(componentConf!-null) { 
conf.put(Config.TOPOLOGY KRYO REGISTER, 
componentConf 
.get(Config.TOPOLOGY KRYO REGISTER)); 


String rootDir = conf.get(Config.TRANSACTIONAL ZOOKEEPER ROOT) + "/" + id + "/" 
* subroot; 
List<String> servers = (List<String>) getWithBackup(conf, 
Config. TRANSACTIONAL_ZOOKEEPER SERVERS, Config.STORM ZOOKEEPER SERVERS); 


Object port = getWithBackup(conf, Config.TRANSACTIONAL ZOOKEEPER PORT, Config.STORM 


ZOOKEEPER PORT); 
CuratorFramework initter - Utils.newCuratorStarted(conf, servers, port); 
try ( 

initter.create().creatingParentsIfNeeded().forPath(rootDir); 
) catch(KeeperException.NodeExistsException e) { 


} 


initter.close(); 


_curator = Utils.newCuratorStarted(conf, servers, port, rootDir); 
_ser = new KryoValuesSerializer(conf) ; 
_des = new KryoValuesDeserializer(conf); 
} catch (Exception e) { 
throw new RuntimeException(e); 
} 
} 


public void setData(String path, Object obj) { 
path = "/" + path; 
byte[] ser = ser.serializeObject(obj); 
try { 
if( curator.checkExists().forPath(path)!-null) { 
_curator.setData().forPath(path, ser); 
) else { 

_curator.create() 
.creatingParentsIfNeeded() 
.withMode(CreateMode.PERSISTENT) 
.forPath(path, ser); 


} catch(Exception e) { 
throw new RuntimeException(e); 
} 
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59 

60 

61 

62 public List«String» list(String path) { 

63 path = "/" + path; 

64 try { 

65 if( curator.checkExists().forPath(path)--null) { 
66 return new ArrayList<String>(); 

67 ) else ( 

68 return curator.getChildren().forPath(path); 
69 } 

70 } catch(Exception e) { 

71 throw new RuntimeException(e); 

72 } 

73 } 

74 

75 public void mkdir(String path) { 

76 setData(path, 7); 

77 } 

78 

79 public Object getData(String path) { 

80 path = "/" + path; 

81 try { 

82 if( curator.checkExists().forPath(path)!-null) { 
83 return des.deserializeObject( curator.getData().forPath(path)); 
84 ) else ( 

85 return null; 

86 } 

87 } catch(Exception e) { 

88 throw new RuntimeException(e); 

89 } 

90 } 

91 

92 public void close() { 

93 _curator.close(); 

94 } 

95 

96 private Object getWithBackup(Map amap, Object primary, Object backup) { 
97 Object ret = amap.get(primary) ; 

98 if(ret==null) return amap.get(backup) ; 

99 return ret; 

100 } 

101 } 


口 第 2 行 定 义 一 个 Curator 的 成 员 变 量 。 


ZooKeeper 中 的 自 定义 类 ， 需 要 进行 Kyro 的 注册 ， 否 则 将 无 法 写作 ZooKeeper。 


口 第 17~22 行 用 来 获取 用 户 注 册 的 使 用 Kyro 序 列 化 的 类 型 。 


口 第 3~4 行 定义 序列 化 以 及 反 序列 化 的 成 员 变 量 , 这 里 利用 Kyro 进 行 序列 化 。 对 于 要 存放 到 


口 第 6~12 行 定义 了 两 个 工具 方法 ， 分 别 对 应 于 user 和 coordinator 子 目录 。 其 中 coordinator 子 目 
录用 于 为 协调 Spout 节 点 存储 元 数据 。 关 于 “user” 子 目录 ,本 书 会 在 1$.6.2 节 进一步 讨论 。 
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口 第 23 行 产生 事务 Topology 用 于 存储 元 数据 的 ZooKeeper 路 径 。 通 常 ,TRANSACTIONAL_ any 
ZOOKEEPER_ROOTHY{H Ay/transactional; id 为 Spout 节 点 名 字 ， 该 名 字 是 在 创建 Topology 时 指 
定 的 ; subroot 为 user 或 者 coordinator。 例 如 ， 若 Spout 的 名 字 为 TestSpout， 则 元 数据 的 路 径 
为 /transactional/TestSpout/coordinator。 每 次 提交 同样 的 Topology 时 ，Storm 会 产生 不 同 的 
TopologyId 以 作 区 分 ， 但 Spout 节 点 名 字 是 固定 的 。 于 是 重新 提交 的 Topology 会 继续 访问 上 
一 个 Topology 在 ZooKeeper 中 存储 的 元 数据 , 也 就 实现 了 从 上 一 个 Topology 结 束 点 继续 执行 
的 目标 。 这 也 是 事务 Topology 可 以 实现 可 靠 消 息 传输 的 原因 之 一 。 

口 第 24~25 行 用 来 获取 ZooKeeper 的 服务 器 名 称 及 端口 号 。Storm 本 身 需 要 利用 ZooKeeper 来 
存储 一 些 元 数据 , 而 事务 Topology 中 存储 的 元 数据 更 接近 于 用 户 数据 , 原则 上 应 使 用 分 开 
的 ZooKeeper 服务 器 进行 存储 。Storm 提 供 了 这 样 的 灵活 性 ， 如 果 设 置 了 
TRANSACTIONAL ZOOKEEPER SERVERS, W) Storm 会 利用 该 配置 项 制定 的 ZooKeeper 来 存储 数 
据 ， 否 则 就 使 用 默认 的 STORM_ZOOKEEPER_SERVERS。 

口 第 26~31 行 利用 CuratorFramework 来 创建 根 目录 。 由 于 根 目录 是 相对 固定 的 ， 只 需要 创建 
一 次 , 因此 ZooKeeper 在 创建 节点 时 并 不 会 再 次 创建 根 目录 。 例如 , 车 目录 结构 为 /a/b/c/d， 
则 在 创建 节点 d 之 前 需要 预先 依次 为 其 创建 父 节 点 a、b、c。 

口 第 35 行 重新 创建 Curator 对 象 并 传人 已 经 创建 好 的 根 目 录 。 接 下 来 的 ZooKeeper 操 作 均 基于 
这 个 根 目录 , 相 比 于 每 次 都 重新 根据 ZooKeeper 的 根 目录 “/” 来 确定 存储 路 径 的 过 程 , Storm 
采用 的 这 种 方法 提高 了 使 用 ZooKeeper 的 效率 。 

a 第 36~37 行 创建 序列 化 和 反 序列 化 对 象 。 

O 第 43~58 行 是 setData 方 法 的 实现 。 由 于 ZooKeeper 中 只 能 存储 字 节 数组 ， 因 此 该 方法 会 首 
先 将 输入 的 对 象 序列 化 。 如 果 数 据 节 点 已 经 存在 ， 则 直接 设置 数据 ; 若 不 存在 ， 则 创建 
节 后 再 设置 数据 。 注 意 ， 传 人 的 路 径 path 可 以 继续 含有 子 目 录 结 构 。 

口 第 62~73 行 将 某 一 个 目录 结构 下 的 全 部 子 节 点 返回 。 当 重新 提交 的 Topology 开 始 运行 后 ， 
就 可 以 通过 该 方法 获取 那些 需要 被 重新 执行 的 事务 。 其 他 的 函数 比较 类 似 ， 这 里 不 再 一 
一 讨论 。 

口 第 96~100 行 的 getNithBackup 函 数 优先 使 用 primary 定 义 的 值 ， 如 果 不 存在 ， 则 使 用 backup 
对 应 的 值 。 

RotatingTransactionalState 类 是 对 TransactionalState 的 进一步 封装 , 它 提供 了 额外 的 两 个 功 

fig: 首先 ， 通 过 在 内 存 中 维护 一 个 TreeMap 结 构 以 优化 查询 速度 ; 其 次 ， 将 不 需要 的 数据 ( 如 已 

经 完成 的 事务 的 元 数据 ) 从 ZooKeeper 中 删除 。ZooKeeper 中 存储 的 数据 节点 增多 可 能 会 导致 各 种 

各 样 的 问题 ， 于 是 清理 ZooKeeper 中 不 再 使 用 的 数据 是 非常 关键 且 必 需 的 步 又。 该 类 的 代码 如 下 : 


/** 
* A map from txid to a value. Automatically deletes txids that have been committed. 
*/ 
public class RotatingTransactionalState { 
public static interface StateInitializer { 
Object init(BigInteger txid, Object lastState); 
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7 } 
8 
9 private TransactionalState state; 
10 private String _subdir; 
11 private boolean strictOrder; 
12 
13 private TreeMap«BigInteger, Object» curr = new TreeMap<BigInteger, Object>(); 
14 
15 public RotatingTransactionalState(TransactionalState state, String subdir, Boolean 
strictOrder) { 
16 _state = state; 
17 _subdir = subdir; 
18 _strictOrder = strictOrder; 
19 state.mkdir(subdir) ; 
20 sync(); 
21 } 
22 
23 public RotatingTransactionalState(TransactionalState state, String subdir) { 
24 this(state, subdir, false); 
25 } 
26 
27 public Object getLastState() { 
28 if(_curr.isEmpty()) return null; 
29 else return curr.lastEntry().getValue(); 
30 ) 
31 
32 public void overrideState(BigInteger txid, Object state) { 
33 _state.setData(txPath(txid), state); 
34 _curr.put(txid, state); 
35 } 
36 
37 public void removeState(BigInteger txid) { 
38 if(_curr.containsKey(txid)) { 
39 _curr.remove(txid) ; 
40 _state.delete(txPath(txid)); 
41 } 
42 } 
43 
44 public Object getState(BigInteger txid, StateInitializer init) { 
45 if(!_curr.containsKey(txid)) { 
46 SortedMap«BigInteger, Object» prevMap = _curr.headMap(txid) ; 
47 SortedMap«BigInteger, Object» afterMap = _curr.tailMap(txid); 
48 
49 BigInteger prev = null; 
50 if(!prevMap.isEmpty()) prev = prevMap.lastKey(); 
51 
52 if(_strictOrder) { 
53 if(prev==null 8& !txid.equals(TransactionalSpoutCoordinator.INIT TXID)) { 
54 throw new IllegalStateException("Trying to initialize transaction for which 
there should be a previous state"); 
55 
56 if(prev!-null 8& !prev.equals(txid.subtract(BigInteger.ONE))) { 
57 throw new IllegalStateException("Expecting previous txid state to be the 


previous transaction"); 
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} 
if(lafterMap.isEmpty()) { 
throw new IllegalStateException("Expecting tx state to be initialized in 
strict order but there are txids after that have state"); 


Object data; 
if(afterMap.isEmpty()) { 
Object prevData; 
if(prev!-null) { 
prevData = curr.get(prev); 
} else { 
prevData = null; 


} 

data = init.init(txid, prevData); 
} else { 

data = null; 


} 
_curr.put(txid, data); 
_state.setData(txPath(txid), data); 
} 
return curr.get(txid); 


} 


public boolean hasCache(BigInteger txid) { 
return curr.containsKey(txid); 
) 


/** 
* Returns null if it was created, the value otherwise. 
4 
public Object getStateOrCreate(BigInteger txid, StateInitializer init) { 
if( curr.containsKey(txid)) { 
return curr.get(txid); 
) else ( 
getState(txid, init); 
return null; 


} 


public void cleanupBefore(BigInteger txid) { 
SortedMap«BigInteger, Object» toDelete = _curr.headMap(txid) ; 
for (BigInteger tx: new HashSet<BigInteger>(toDelete.keySet())) { 
_curr.remove(tx); 
_state.delete(txPath(tx)); 


} 


private void sync() { 
List<String> txids = state.list( subdir); 
for(String txid_s: txids) { 
Object data = _state.getData(txPath(txid_s)); 
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111  curr.put(new BigInteger(txid s), data); 
112 

113 } 

114 

115 private String txPath(BigInteger tx) { 
116 return txPath(tx.toString()); 

117 } 

118 

119 private String txPath(String tx) { 

120 return subdir + "/" + tx; 

121 } 

122 } 


a 第 5~7 行 定义 接口 stateInitializer ， 该 接口 用 于 表明 如 何 初始 化 事务 元 数据 。 在 事务 
Topology 中 ， 该 接口 中 定义 的 in 让 方法 将 调用 ITransactionalSpout. initializeTransac 
tion 方 法 来 产生 新 事务 所 对 应 的 元 数据 。 

O 第 9~11 行 定义 了 3 个 成 员 变量 , 其 中 _state 对 象 用 来 操作 ZooKeeper，_subdir 表 示 子 目录 ， 
_strictOrder 则 用 来 表明 创建 的 事务 是 否 需 要 满足 强 序 列 。 由 于 Storm 可 以 根据 上 一 个 事 
务 的 元 数据 来 初始 化 当前 事务 ， 所 以 事务 之 间 是 存在 一 定 联系 的 ， 这 时 就 需要 保证 事务 
初始 化 的 强 序 列 。 基 础 事务 Topology 中 使 用 了 强 序列 。 

O 第 13 行 定义 了 _curz 成 员 变 量 ， 它 为 TreeMap 对 象 。 其 存储 的 数据 与 ZooKeeper 中 的 一 致 ， 

即 Storm 同 时 维护 了 内 存 中 的 数据 及 ZooKeeper 中 的 数据 。 

a 第 15~21 行 定义 的 构造 函数 用 于 对 象 的 初始 化 。 第 20 行 会 调用 sync 方 法 ， 根 据 ZooKeeper 
中 已 经 存在 的 数据 构建 _curr 对 象 。sync 方 法 在 第 107~113 行 定义 。 可 以 看 出 ，Storm 用 事 
务 序号 作为 ZooKeeper 路 径 的 一 部 分 。 

a 第 27~42 行 定义 了 一 些 读 写 方法 。 读 时 会 从 _curz 返 回 结果 ; 写 时 首先 更 新 ZooKeeper 中 的 

数据 ， 然 后 更 新 内 存 中 的 数据 。 

O 第 44~81 行 定义 了 getState 方 法 ， 其 参数 为 BigInteger 类 型 的 事务 序号 ， 以 及 一 个 用 于 初始 
化 一 个 新 事务 的 回调 函数 init。 如 果 该 事务 序号 所 对 应 的 元 数据 已 经 被 创建 ， 则 在 第 80 行 

直接 返回 ; 若 未 创建 ， 这 个 类 首先 将 _curr 分 成 两 个 部 分 ， 一 部 分 是 均 比 事务 序号 要 小 的 事 
F, 将 其 放 在 preMap 中 ， 男 一 部 分 是 均 比 事务 序号 要 大 的 事务 ,将 其 放 在 afterMap 中 。prev 
表示 比 当 前 事务 序号 小 的 最 大 的 事务 序号 。 如 果 _strictOrder 为 true， 将 进行 如 下 检查 。 
prev 为 空 ， 并 且 当 前 事务 序号 不 为 1。 

m prev pN, a 
m afterMap 为 空 ， 即 含有 比 当前 txid 更 大 序号 的 事务 已 经 初始 化 了 。 

口 ee 的 元 数据 。 第 66~73 行 对 应 于 当前 事务 序号 即 为 最 大 事务 
序号 的 ' lise 此 时 Storm 会 获取 上 一 个 事务 的 元 数据 ， 同 时 调用 :init 方法 获取 当前 事务 的 
元 数据 。 第 75 行 对 应 于 当前 的 事务 序号 并 不 是 最 大 事务 序号 的 情况 ， 这 种 情况 也 即 当 

_strictOrder 为 false 的 情况 ， 这 表明 已 经 有 后 面 的 事务 被 初始 化 了 ， 并 且 利 用 的 是 当前 
事务 的 前 一 个 事务 的 元 数据 ， 此 时 Storm 会 将 当前 事务 的 元 数据 设置 为 空 。 在 非 强 序 的 情 


15.3 ”协调 Spout 节点 的 执行 器  —255 


况 下 ,用 户 代码 应 更 加 小 心 ， 它 需要 根据 当前 获得 的 元 数据 是 否 为 空 来 进行 之 后 的 操作 ， 
或 者 将 其 忽略 或 者 给 予 特殊 地 处 理 。 
OQ 第 77~78 行 依次 更 新 内 存 及 ZooKeeper 中 的 数据 。 个 人 认为 颠倒 这 两 行 的 顺序 可 能 更 好 ， 
即 先 更 新 ZooKeeper 中 的 数据 。 
口 第 90~97 行 定义 了 getState0rCTeate 方 法 。 如 果 元 数据 已 经 创建 过 ， 则 返回 该 元 数据 ; 如 
果 未 创建 ， 则 调用 getstate 方 法 创建 ， 但 返回 值 为 空 。 它 主要 用 在 消息 发 送 Bolt 节 点 上 ， 
以 表明 是 第 一 次 处 理事 务 。 这 个 方法 的 目的 是 有 些 奇怪 的 。 
口 第 99~105 行 定义 的 cleanupBefore 也 数 负责 对 已 经 完成 的 事务 进行 清理 。 由 于 事务 提交 是 
强 序 的 ， 所 以 当前 事务 被 提交 时 ， 之 前 的 事务 都 已 经 完成 了 ， 故 清理 这 些 数据 是 安全 的 。 
利用 TreeMap 结 构 来 获得 需要 清除 的 事务 序号 是 非常 方便 的 。 读 者 可 以 思考 一 下 ,如 果 直 
接 操 作 ZooKeeper， 又 应 如 何 实现 。 
在 下 一 节 中 ， 我 们 将 讨论 如 何 基于 TransactionalState 和 RotatingTransactionalState 类 来 实 
现 协调 Spout 的 执行 器 。 


15.3.2 ”协调 Spout 的 执行 器 


TransactionalSpoutCoordinator 类 继承 自 类 BaseRichspout， 而 BaseRichSpout 又 将 实现 接口 
IRichSpout， 具 体 的 类 关系 如 图 15-2 所 示 。 


1 ISpout 
® open(Map, TopologyContext , SpoutOutputCollector) void 
m dose() void 1 IComponent 
activat) void @ dedareOutputFields(OutputFieldsDecarer) void 
@ deactivate() void a getComponentConfiguration() Map<String,Object> 
@ nextTuple() void - x 
@ ack (Object) void | 
@ fail(Object) void 

: IRichSpout € BaseComponent 

m getComponentConfiguration() Map<String,Object> 


1 
© BaseRichSpout 


m dose() void 
m activate() void 
(m deactivate() void 
(@ack(Object) void 
m fail (Object) void 


€ TransactionalSpoutCoordinator 


m getSpout() ITransactionalSpout 
$$ open(Map, TopologyContext, SpoutOutptCollector) void 
m@dose() void 
& nextTuple() void 
@ack(Object) void 
$$ fail (Object) void 


a dedareOutputFields(OutputFieldsDedarer) void 
a getComponentConfiguration() Map<String,Object> 


图 15-2 TransactionalSpoutCoordinator 的 类 关系 
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TransactionalSpoutCoordinator 类 使 用 内 部 私有 类 AttemptStatus 来 表 
状态 ， 其 代码 如 下 : 


private static enum AttemptStatus ( 
PROCESSING, 
PROCESSED, 
COMMITTING 


其 中 各 个 成 员 变量 的 含义 如 下 。 
口 PROCESSING: 事务 尝试 消息 已 经 从 协调 Spout 发 送出 去 ， 表 明 当 前 


"i 


示 一 个 事务 尝试 的 3 种 


开始 处 理 。 
口 PROCESSED: 该 事务 已 经 被 处 理 完成 并 等 待 提交 。 


EI 所 对 应 的 数据 已 经 


O COMMITTING: 该 事务 之 前 的 事务 都 已 被 提交 ， 于 是 发 送 消 息 到 提交 Bolt， 表 示 当 前 的 事务 


也 可 以 被 提交 了 。 在 协调 Spout 收 到 这 条 消息 的 Ack 后 ， 当 前 事务 就 被 认为 是 已 经 成 功 处 


Md 


里 了 ， 此 时 可 以 开始 一 个 新 事务 。 


接 下 来 ， 分 析 TransactionalSpoutCoordinator 类 的 实现 ， 其 代码 如 下 : 


1 public class TransactionalSpoutCoordinator extends BaseRichSpout { 

2 public static final Logger LOG = LoggerFactory.getLogger(TransactionalSpoutCoordinator.class); 

3 

4 public static final BigInteger INIT TXID = BigInteger.ONE; 

5 

6 public static final String TRANSACTION BATCH STREAM ID - TransactionalSpoutCoordinator. 
class.getName() + "/batch"; 

7 public static final String TRANSACTION COMMIT STREAM ID = TransactionalSpoutCoordinator. 
class.getName() + "/commit"; 

8 

9 private static final String CURRENT TX = "currtx"; 

10 private static final String META DIR - "meta"; 

11 

12 private ITransactionalSpout _spout; 

13 private ITransactionalSpout.Coordinator coordinator; 

14 private TransactionalState state; 

15 private RotatingTransactionalState  coordinatorState; 

16 

17 TreeMap«BigInteger, TransactionStatus> _activeTx = new TreeMap«BigInteger, Transaction 
Status»(); 

18 

19 private SpoutOutputCollector collector; 

20 private Random rand; 

21 BigInteger _currTransaction; 

22 int _maxTransactionActive; 

23 StateInitializer initializer; 

24 

25 

26 public TransactionalSpoutCoordinator(ITransactionalSpout spout) { 

27 _spout = spout; 


28 } 
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public ITransactionalSpout getSpout() ( 
return spout; 
} 


@Override 

public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) { 
rand = new Random(Utils.secureRandomLong()); 
state = TransactionalState.newCoordinatorState(conf, (String) 

conf.get(Config.TOPOLOGY TRANSACTIONAL ID),  spout.getComponentConfiguration()); 

_coordinatorState = new RotatingTransactionalState( state, META DIR, true); 
collector - collector; 
coordinator = _spout.getCoordinator(conf, context); 
 currTransaction - getStoredCurrTransaction( state); 
Object active - conf.get(Config.TOPOLOGY MAX SPOUT PENDING); 
if(active--null) ( 


_maxTransactionActive = 1; 
} else { 
_maxTransactionActive = Utils.getInt(active) ; 
} 
_initializer = new StateInitializer(); 
} 
@Override 


public void close() { 
_state.close(); 
} 


@Override 
public void nextTuple() { 


sync(); 
} 


@Override 

public void declareOutputFields(OutputFieldsDeclarer declarer) { 
// in partitioned example, in case an emitter task receives a later transaction than it's 
// emitted so far, when it sees the earlier txid it should know to emit nothing 
declarer.declareStream(TRANSACTION BATCH STREAM ID, new Fields("tx", "tx-meta", 
"committed-txid")); 
declarer.declareStream(TRANSACTION COMMIT STREAM ID, new Fields("tx")); 


@Override 

public Map<String, Object> getComponentConfiguration() { 
Config ret = new Config(); 
ret.setMaxTaskParallelism(1) ; 
return ret; 


} 


private BigInteger nextTransactionId(BigInteger id) { 
return id.add(BigInteger.ONE); 
} 


private BigInteger previousTransactionId(BigInteger id) { 
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81 if(id.equals(INIT TXID 
82 return null; 

83 j else ( 

84 return id.subtract 
85 } 

86 } 

87 

88 private BigInteger getStor 
89 BigInteger ret = (BigI 
90 if(ret==null) return I 
91 else return ret; 

92 

93 } 


) { 


(BigInteger.ONE); 


edCurrTransaction(TransactionalState state) { 
nteger) state.getData(CURRENT TX); 
NIT TXID; 


O 第 4 行将 INIT_TXID 定 义 为 1， 表 示 事 务 序 号 都 是 从 1 开始 的 。 
O 第 6 行 定 义 TRANSACTION_BATCH_STREAM_ID， 事 务 尝试 消息 将 被 发 送 到 这 个 流 。 所 有 消息 发 


送 Bolt 都 会 通过 直接 分 组 的 方式 来 接收 这 个 流 的 消息 。 它 的 模式 为 <"tx", "tx-meta"， 
"committed-txid"», 其 中 tx 为 TransactionalAttempt 对 象 , tx-meta 为 用 户 自 定义 的 事务 元 
数据 ，committed-txid 表 示 上 一 个 已 经 提交 的 事务 序号 ( 在 Bolt 中 ， 可 以 利用 该 值 对 数据 


进行 清理 )。 


O 第 7 行 定义 TRANSACTION_COMMIT_STREAM ID， 用 于 发 送 事 务 提交 的 消息 。 所 有 的 事务 提交 
Bolt 节 点 都 会 通过 直接 分 组 的 方式 来 接收 这 个 流 的 消息 。 它 的 模式 是 "tx">， 作 用 为 通知 
事务 提交 Bolt 事 务 txid 已 经 处 理 结束 了 。txId 对 应 的 事务 及 其 之 前 的 事务 都 已 经 处 理 结 


是 一 个 非常 重要 的 时 间 点 ， 该 时 间 点 保证 了 finishBatch 是 按照 事务 的 顺序 被 调用 的 。 


号 ，meta 用 来 存储 系统 中 所 有 
O 第 12~13 行 定义 代理 的 ITransa 
O 第 14~15 行 定义 的 对 象 用 于 操 
State 则 用 来 维护 正在 处 理 的 引 


前 事务 处 于 何 种 状态 的 信息 。 
个 对 象 ， 其 代码 如 下 : 


口 第 9~10 行 定义 了 ZooKeeper 中 两 个 子 目 录 的 名 称 ，currtx 用 来 存储 当前 等 待 提交 的 事务 序 


正在 执行 的 事务 序号 。 

ctionalSpout 及 其 协调 Spout 对 象 。 

作 ZooKeeper，_state 用 来 维护 当前 的 事务 ，_coordinator 
EZ o 


口 第 17 行 的 activeTx 表 示 正 在 处 理事 务 。 与 _coordinateState 不 同 ，_activeTx 还 保存 着 当 


这 里 涉及 的 TransactionSstatus 类 包含 attempt 和 status 这 两 


private static class TransactionStatus ( 


TransactionAttempt attempt; 
AttemptStatus status; 


public TransactionStatus(TransactionAttempt attempt) { 


this.attempt - attempt; 


this.status - AttemptStatus.PROCESSING; 


} 


@Override 
public String toString() { 
return attempt. toString( 


) +" <" + status.toString() + ">"; 
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} 


O 第 20 行 定义 的 _rand 随 机 函数 用 于 产生 事务 的 尝试 序号 。 

是 相同 的 ， 而 事务 尝试 序号 是 不 同 的 。 

O 第 23 行 实现 接口 stateInitializer, 它 会 调用 initializeTransaction 方 法 来 初始 化 一 个 与 

事务 相对 应 的 元 数据 ,其 代码 如 下 : 

private class StateInitializer implements RotatingTransactionalState.StateInitializer { 
(QOverride 


public Object init(BigInteger txid, Object lastState) { 
return coordinator.initializeTransaction(txid, lastState); 
} 


qlip 


务 在 进行 重 传 时 ， 其 事务 序号 


} 


口 第 35~49 行 实现 了 Spout 的 open 方 法 。 该 方法 将 负责 与 ZooKeeper 中 的 元 数据 同步 ， 将 之 前 
未 处 理 完 的 事务 的 元 数据 恢复 到 内 存 中 , 并 进行 重 传 。 这 是 事务 Topology 可 以 实现 可 靠 处 
理 的 基础 。 在 第 38 行 中 ， 初 始 化 RotatingTransactionalState 对 象 的 最 后 一 个 参数 被 设置 
为 true， 表 示 将 开启 对 元 数据 对 象 初始 化 顺序 的 检查 。 

口 第 42 行 中 ， 参 数 TOPOLOGY_MAX_SPOUT_PENDING 表 示 最 多 可 以 有 多 少 个 事务 在 系统 中 被 同时 
执行 ， 其 默认 值 为 1。 

在 分 析 TransactionalSpoutCoordinator 的 其 他 方法 之 前 ， 我 们 首先 来 介绍 sync 方 法 ， 其 代码 

如 下 : 


iln. 


1 private void sync() ( 

2 // note that sometimes the tuples active may be less than max spout pending, e.g. 

3 // max spout pending - 3 

4 // tx 1, 2, 3 active, tx 2 is acked. there won't be a commit for tx 2 (because tx 1 isn't 
committed yet), 

5 // and there won't be a batch for tx 4 because there's max spout pending tx active 

6 TransactionStatus maybeCommit = _activeTx.get(_currTransaction) ; 

7 if(maybeCommit!-null && maybeCommit.status == AttemptStatus.PROCESSED) { 

8 maybeCommit.status = AttemptStatus.COMMITTING; 

9 _collector.emit (TRANSACTION COMMIT STREAM ID, new Values(maybeCommit.attempt) , 

maybeCommit.attempt); 


10 } 

11 

12 try { 

13 if(_activeTx.size() < _maxTransactionActive) { 

14 BigInteger curr = _currTransaction; 

15 for(int i=0; i<_maxTransactionActive; i++) { 

16 if((_coordinatorState.hasCache(curr) || _coordinator.isReady()) 

17 && ! activeTx.containsKey(curr)) { 

18 TransactionAttempt attempt = new TransactionAttempt(curr, rand. 
nextLong()); 

19 Object state = coordinatorState.getState(curr, _initializer); 

20 _activeTx.put(curr, new TransactionStatus(attempt)); 


21  collector.emit(TRANSACTION BATCH STREAM ID, new Values(attempt, state, 
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previousTransactionId( currTransaction)), attempt); 

E curr - nextTransactionId(curr); 

24 } 

25 } 

26 ) catch(FailedException e) { 

27 LOG.warn("Failed to get metadata for a transaction", e); 

TE 

O 第 2~5 行 的 注释 是 很 重要 的 ， 即 表示 目前 活跃 的 事务 序号 为 1!1、2、3， 此 时 事务 序号 2 已 经 
进行 Ack 操 作 了 , 但 是 由 于 事务 序号 1 还 没有 进行 Ack 操 作 , 所 以 当前 的 事务 序号 currTxId 
还 只 能 为 1。 于 是 ， 此 时 系统 中 活跃 的 事务 只 有 事务 1 和 3， 少 于 参数 maxSpoutPending 所 定 
义 的 活跃 事务 数目 。 

口 第 6~10 行 检查 _currTransaction 所 对 应 的 事务 是 否 已 经 处 于 PROCESSED 状 态 , 如 果 是 , 则 将 
事务 的 状态 改 成 COMMITTING， 并 向 提交 消息 流 发 送 消息 ， 同 时 将 TransactionalAttempt 作 
为 消息 跟踪 ID，Storm 需 要 对 这 条 消息 进行 跟踪 。 只 有 在 收 到 该 消息 的 Ack 之 后 ，_curr 
Transaction 才 会 指向 下 一 个 事务 序号 ， 这 是 保证 提交 消息 为 强 序 的 关键 。 

a 第 12~25 行 对 可 能 的 事务 进行 初始 化 。 若 _activeTx 的 元 素数 目 比 _maxTransactionActive 
的 小 , 表示 可 以 继续 初始 化 新 的 事务 并 使 其 运行 , 此 时 Storm 采 用 了 一 种 更 为 激进 的 方式 ， 
它 会 逐一 检查 从 事务 序号 currTransaction 到 事务 序号 currTransaction* max 
TransactionActive-1 的 事务 是 否 都 已 经 被 初始 化 。 这 可 以 在 某 种 程度 上 抑制 数据 不 同步 
的 情况 产生 。 

O 第 16~17 行 的 条 件 很 重要 ， 可 以 这 么 理解 。 

m _activeTx 中 不 包含 当前 事务 curr,， 但 _coordinatorstate 中 却 包 含 了 当前 事务 curr。 这 
表明 _coordinatorState 与 _activeTx 不 同步 ， 系 统 将 重新 发 送 这 条 事务 消息 。 这 是 有 可 
能 发 生 的 , 例如 一 个 Topology 在 被 杀 掉 后 重新 提交 ，_coordinatorSstate 中 会 包含 上 一 个 
Topology 未 完成 的 事务 序号 ， 而 _activeTx 中 却 并 不 会 包含 这 些 信 息 ，Storm 需 要 对 这 样 
的 事务 进行 重 传 处 理 。 

_activeTx 中 不 包含 当前 事务 curr，_coordinatorState 中 也 不 包含 当前 事务 curr， 同 时 

isReady 孙 数 返回 为 true， 此 时 表明 可 以 开始 一 个 新 事务 ， 并 且 数 据 已 经 准备 好 了 ， 系 

统 此 时 将 发 送 一 条 新 的 事务 尝试 消息 。 这 部 分 逻辑 还 是 有 问题 的 ， 例 如 若 

maxTransactionActive=2， 当 txId=1H 时 ，isReady 返 回 为 false， 序 号 为 1 的 事务 并 未 初始 

化 成 功 ; 然而 当 txId=2 时 ，isReady 返 回 为 true，Storm 试 图 初始 化 序号 为 2 的 事务 。 但 

是 由 于 序号 为 1 的 事务 并 未 初始 化 ， 此 时 将 不 满足 元 数据 的 强 序 检查 ， Storm 会 因此 推 

出 异常 。Topology 在 刚刚 启动 时 更 容易 发 生 这 个 问题 。 

接 下 来 ， 对 Spout 的 ack 方 法 进行 分 析 ， 其 代码 如 下 : 


1 @Override 
2 public void ack(Object msgId) { 
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3 TransactionAttempt tx = (TransactionAttempt) msgId; 

4 TransactionStatus status = activeTx.get(tx.getTransactionId()); 
5 if(status!-null && tx.equals(status.attempt)) { 

6 if(status.status--AttemptStatus.PROCESSING) { 

7 status.status - AttemptStatus.PROCESSED; 

8 } else if(status.status--AttemptStatus.COMMITTING) { 


9 _activeTx. remove(tx.getTransactionId()); 

10 . coordinatorState.cleanupBefore(tx.getTransactionId()); 

11 _currTransaction = nextTransactionId(tx.getTransactionId()); 
12 _state.setData(CURRENT TX, currTransaction); 

13 } 

14 sync(); 

15  } 

16 } 


Q ack 方 法 可 能 收 到 从 两 个 发 送 流 输 出 的 消息 的 Ack， 但 是 这 里 没有 办 法 区 分 ， 只 能 根据 

务 的 状态 进行 区 分 。msgId 实 际 上 为 TransactionAttempt 对 象 。 

口 在 第 5 行 中 ， 如 果 Ack 回 来 的 事务 尝试 消息 与 _activeTx 中 的 不 同 ， 则 忽略 这 条 消息 ， 它 

可 能 是 某 个 已 经 丢弃 的 重 传 的 事务 。 

O 在 第 6~7 行 中 ， 如 果 状 态 为 PROCESSING， 表 明 数 据 处 理 已 经 结束 了 ， 因 此 随即 将 其 状态 

成 PROCESSED。 

O 在 第 8~13 行 中 ， 若 状态 为 COMMITTING， 表 明 收 到 了 从 事务 提交 Bolt 返 回来 的 Ack 消 息 ， 
味 着 事务 处 理 已 经 结束 ， 接 下 来 进行 数据 清理 。 第 12 行 将 _currTransaction 更 新 为 下 一 
事务 序号 ， 以 保证 强 序 关 系 。 

口 第 14 行 调用 了 sync 方 法 ， 因 为 此 时 有 机 会 产生 新 事务 。 

最 后 对 Spout 的 fail 方 法 进行 分 析 ， 其 实现 较为 简单 ， 相 关 代 码 如 下 : 


@Override 
public void fail(Object msgId) { 
TransactionAttempt tx = (TransactionAttempt) msgId; 
TransactionStatus stored = activeTx.remove(tx.getTransactionId()); 
if(stored!-null 8& tx.equals(stored.attempt)) { 
_activeTx.tailMap(tx.getTransactionId()).clear(); 
sync(); 


} 

注意 当 某 一 个 事务 处 理 失 败 时 ，Storm 将 重 传 这 个 事务 之 后 的 所 有 事务 。 

TransactionalSpoutCoordinator 类 还 有 一 些 其 他 方法 ， 但 都 比较 直观 ， 这 里 不 再 歼 述 。 
15.3.3 ”消息 发 送 Bolt 的 执行 器 


类 似 地 ，TransactionalSpoutBatchExecutor 类 用 来 执行 ITransactionalSpout 中 消息 发 送 B 
的 接口 ， 它 是 Bolt 类 型 的 。 
我 们 首先 介绍 接口 ICommitterTiransactionalSpout ， 其 代码 如 下 : 


事 


很 
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=i 
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public interface ICommitterTransactionalSpout<X> extends ITransactionalSpout<X> { 
public interface Emitter extends ITransactionalSpout.Emitter { 
void commit(TransactionAttempt attempt); 
} 


@Override 
public Emitter getEmitter(Map conf, TopologyContext context); 


} 

该 接口 为 ITransactionalSpout.Emitter 添 加 了 一 个 commit 方 法 。 通 常 ， 事 务 的 元 数据 是 在 协 
调 Spout 中 产生 并 被 清理 的 , 但 它 也 可 能 由 消息 发 送 节点 在 emitBatch 时 产生 ， 此 时 协调 Spout 节 点 
并 没有 足够 的 数据 对 元 数据 进行 操作 ,因此 元 数据 需要 在 消息 发 送 节点 中 进行 处 理 。 目 前 ， 这 个 
接口 主要 用 来 文 持 模糊 事务 Topology。 

下 面 分 析 TransactionalSpoutBatchExecutor 的 实现 , 该 类 实现 IRichBolt 接 口 , 表示 该 节点 本 
质 上 为 Bolt 节 点 ， 其 代码 如 下 : 


iini 


1 public class TransactionalSpoutBatchExecutor implements IRichBolt { 

2 public static Logger LOG = LoggerFactory.getLogger(TransactionalSpoutBatchExecutor.class) ; 

3 

4 BatchOutputCollectorImpl collector; 

5 ITransactionalSpout  spout; 

6 ITransactionalSpout.Emitter emitter; 

7 

8 TreeMap«BigInteger, TransactionAttempt» _activeTransactions = new TreeMap«BigInteger, 
TransactionAttempt>(); 

9 

10 public TransactionalSpoutBatchExecutor(ITransactionalSpout spout) { 

11 _spout = spout; 

12 } 

13 

14 @Override 

15 public void prepare(Map conf, TopologyContext context, OutputCollector collector) { 

16 collector = new BatchOutputCollectorImpl(collector); 

17 emitter = _spout.getEmitter(conf, context); 

18 j 

19 

20 GOverride 

21 public void cleanup() ( 

22 _emitter.close(); 

23 } 

24 

25 @Override 

26 public void declareOutputFields(OutputFieldsDeclarer declarer) { 

27 _spout.declareOutputFields (declarer); 

28 } 

29 

30 @Override 

31 public Map<String, Object> getComponentConfiguration() { 

32 return _spout.getComponentConfiguration() ; 

33 } 
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a 第 5~6 行 定义 了 类 的 成 员 变量 spout 和 _emitter, 其 中 后 者 由 _spout .getEmitter 方 法 获得 ， 

即 用 户 定义 的 消息 发 送 节点 。 

O 第 8 行 定义 的 _activeTransactions 维 护 了 正在 运行 的 事务 。 不 同 于 协作 Spout 市 点 , 消息 发 
送 节 点 可 能 存在 多 个 并 行 度 。_activeTransactions 主 要 为 模糊 事务 Topology 服 务 。 

该 类 的 其 他 方法 比较 简单 ， 这 里 主要 分 析 其 execute 方 法 的 实现 ， 其 代码 如 下 : 

1 @Override 

2 public void execute(Tuple input) ( 


3 TransactionAttempt attempt = (TransactionAttempt) input.getValue(0); 
4 try ( 
5 


if(input.getSourceStreamId().equals(TransactionalSpoutCoordinator.TRANSACTION COMMIT 
STREAM ID)) { 


6 if(attempt.equals( activeTransactions.get(attempt.getTransactionId()))) ( 
7 ((ICommitterTransactionalSpout.Emitter) _emitter).commit(attempt) ; 
8 _activeTransactions.remove(attempt.getTransactionId()); 

9 _collector.ack(input) ; 

10 } else { 

11 _collector.fail(input) ; 

12 } 

13 } else { 

14 _emitter.emitBatch(attempt, input.getValue(1), collector); 
15 _activeTransactions.put(attempt.getTransactionId(), attempt); 
16 _collector.ack(input) ; 

17 BigInteger committed = (BigInteger) input.getValue(2); 

18 if(committed!=null) { 

19 // valid to delete before what's been committed since 

20 // those batches will never be accessed again 

21 _activeTransactions.headMap(committed) .clear(); 

22 _emitter.cleanupBefore(committed) ; 

23 } 

24 } 

25 } catch(FailedException e) { 

26 LOG.warn("Failed to emit batch for transaction", e); 

27 _collector.fail(input) ; 

28 } 

29 } 


口 第 3 行 从 输入 消息 的 第 1 列 获得 事务 尝试 消息 。 在 事务 Topology 中 ， 限 定 第 1 列 的 值 必须 为 

事务 尝试 消息 。 

口 在 第 6~12 行 中 ， 若 输入 的 消息 来 自 于 流 TRANSACTION_COMMIT_STREAM_ ID， 则 表示 当前 的 事 
务 已 经 结束 执行 ， 可 以 开始 对 元 数据 的 提交 操作 。 只 有 当 _spout 实 现 了 接口 ICommitteT 
TransactionalSpout/ri ，Spout 节 点 才 会 接收 协调 Spout 节点 的 TRANSACTION COMMIT - 
STREAM_ID 流 。 由 于 消息 发 送 节点 的 并 行 度 可 以 大 于 1， 所 以 对 于 同一 个 事务 ， 元 数据 提交 
方法 commit 可 能 会 被 调用 多 次 。 本 书 会 在 模糊 事务 Topology 的 实现 中 对 其 进行 进一步 分 析 。 

口 第 14~23 行 处 理 来 自 于 TRANSACTION_BATCH_STREAM_ID 流 的 消息 ,输入 消息 的 第 1 列 为 事务 所 

对 应 的 元 数据 。 第 14 行 调用 _emitter 的 emitBatch 方 法 。 第 15 行 对 输入 的 消息 进行 Ack 操 作 。 

输入 消息 的 第 2 列 为 已 经 提交 的 事务 序号 ， 表 示 该 事务 之 前 的 事务 都 已 经 被 成 功 处 理 了 ， 
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于 是 可 以 据 此 清理 变量 activeTransactions。 


a 第 22 行 调用 emitter 的 cleanupBefore 回 调 方法 ， 以 清理 用 户 代 码 中 的 历史 事务 数据 。 


15.4 CoordinatedBolt 的 实现 分 析 


CoordinatedBolt 是 非常 关键 的 一 个 类 ， 它 用 于 协调 系统 中 的 Bolt 节 点 。 对 于 事务 Topology 在 
一 个 Bolt 节 点 中 ， 知 能 获知 属于 某 一 个 事务 的 消息 是 否 已 经 全 部 收 到 ， 这 将 是 非常 有 帮助 的 。 

CoordinatedBolt 会 记录 自身 发 送 至 目标 节点 的 消息 数目 ， 当 属于 一 个 事务 的 消息 发 送 结 
Jn, 它 通过 直接 分 组 的 方式 向 协调 流 发 送 一 条 消息 , 通知 目标 节点 需要 从 该 CoordinatedBolt 接 收 
多 少 条 消息 。 

事务 Topology 中 Bolt 节 点 都 利用 CoordinatedBolt 进 行 包装 ， 它 期 待 从 上 游 节点 收 到 这 些 协调 
消息 以 判断 属于 一 个 事务 的 消息 是 否 收 全 , 并 在 收 全 一 个 事务 的 消息 后 , 向 它 的 下 游 节 点 发 出 其 
需要 接收 的 消息 数目 的 通知 。 

CoordinatedBolt 节 点 收 到 并 处 理 完 属于 一 个 事务 的 全 部 消息 后 ， 将 调用 finishBatch 方 法 。 
finishBatch 方 法 是 事务 Topology 中 非常 重要 的 方法 ， 在 事务 提交 节点 中 ， 它 用 于 存储 事务 处 理 
的 结果 。 当 它 被 调用 时 ， 就 表示 属于 一 个 事务 的 消息 都 已 经 被 成 功 处 理 了 。 


15.4.1 TrackingInfo 


TrackingInfo 是 CoordinatedBolt 将 记录 的 那些 信息 。 每 个 事务 尝试 消息 都 会 对 应 一 个 
TrackingInfo 对 象 ， 也 即 哈 希 表 _ tracked 成 员 变量 的 键 为 事务 尝试 消息 。 重 传 的 事务 将 会 对 应 不 
同 的 TrackingInfo 对 象 。 理 解 这 个 类 里 面 的 成 员 ， 对 于 理解 Coordinated Bolt 是 非常 重要 的 。 该 
类 的 代码 如 下 : 


private TimeCacheMap«Object, TrackingInfo> tracked; 
public static class TrackingInfo { 
int reportCount - 0; 
int expectedTupleCount - 0; 
int receivedTuples - 0; 
boolean failed - false; 
Map«Integer, Integer» taskEmittedTuples = new HashMap<Integer, Integer>(); 
boolean receivedId - false; 
boolean finished - false; 
List«Tuple» ackTuples = new ArrayList<Tuple>(); 


) 

下 面 简 要 介绍 该 类 的 成 员 变量 。 

口 reportCount: 用 来 表示 已 经 收 到 的 数据 源 的 个 数 。 一 个 Bolt 节 点 可 能 从 多 个 节点 接收 消 

息 ， 每 个 上 游 节点 都 需要 向 其 发 送 协调 消息 。 

口 expectedTupleCount: 表示 期 望 收 到 消息 的 总 数目 。 这 个 数目 会 根据 收 到 的 协调 消息 进行 
更 新 ， 该 协调 消息 来 自 协 调 消息 流 。 
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Q receivedTuples: 表示 已 经 收 到 消息 的 总 数目 ， 它 会 在 Coordinated0utputCollector 中 更 新 。 

O failed: 用 来 表示 该 事务 尝试 是 否 已 经 失败 。 

O taskEmittedTuples: 用 来 表示 该 Bolt 发 送出 去 的 消息 数目 ， 以 目标 节点 号 作为 键 。 当 该 
Bolt 已 经 成 功 处 理 完 一 个 事务 之 后 , 它 会 向 每 一 个 目标 节点 发 送 一 条 协调 消息 , 通知 目标 
节点 需要 从 它 这 里 收 到 多 少 条 消息 。 该 协调 消息 将 被 发 送 到 协调 消息 流 。 

O receivedId: 如 果 Bolt 实 现 了 ICommittez 接 口 ， 那 么 只 有 在 收 到 从 协调 Spout 闻 点 发 送 过 来 
的 事务 提交 消息 后 ， 该 变量 才 会 被 设置 为 true。 对 于 普通 的 Bolt， 则 默认 就 被 设 为 true， 
即 普 通 Bolt 节 点 中 处 理 的 事务 序号 不 是 强 序 的 。 

O finished: 用 来 表示 该 事务 处 理 是 否 已 经 结束 。 

O ackTuples: 用 来 表示 收 到 的 元 数据 消息 。 该 消息 有 两 种 类 型 ， 一 种 是 从 协调 Spout 收 到 的 

事务 提交 消息 ， 另 外 一 种 是 从 其 他 协调 Bolt 收 到 的 协调 消息 。 在 事务 Topology 中 ，Storm 

只 对 控制 消息 进行 跟踪 ， 而 对 普通 的 数据 消息 则 不 通过 Ack 框 架 进 行 跟踪 。 


15.4.2 CoordinatedOutputCollector 


CoordinatedBolt 使 用 Coordinated0utputCollector 发 送 数据 。Coordinated0utputCollector 类 


实现 了 IOutputCollector 接 口 ， 它 采用 装饰 模式 ， 含 有 一 个 IOutputCollector 的 代理 ， 并 且 添 加 


了 消 
消息 


息 统 计 功能 。 它 会 统计 发 送 到 目标 节点 的 消息 数目 , 并 在 事务 处 理 完成 后 根据 这 些 统计 到 的 
数目 构建 协调 消息 ， 然 后 将 它们 发 送 至 相应 的 目标 节点 。 该 类 的 代码 如 下 : 


1 public class CoordinatedOutputCollector implements IOutputCollector { 

2 IOutputCollector delegate; 

3 

4 public CoordinatedOutputCollector(IOutputCollector delegate) ( 

5 delegate - delegate; 

6 

7 

8 public List«Integer» emit(String stream, Collection«Tuple» anchors, List«Object» tuple) ( 

9 List<Integer> tasks = _delegate.emit(stream, anchors, tuple); 

10 updateTaskCounts(tuple.get(0), tasks); 

11 return tasks; 

12 } 

13 

14 public void emitDirect(int task, String stream, Collection<Tuple> anchors, List<Object> 
tuple) { 

15 updateTaskCounts(tuple.get(0), Arrays.asList(task)); 

16 _delegate.emitDirect(task, stream, anchors, tuple); 

17 } 

18 

19 public void ack(Tuple tuple) { 

20 Object id = tuple.getValue(0); 

21 synchronized( tracked) { 

22 TrackingInfo track - tracked.get(id); 

23 if (track !- null) 


24 track.receivedTuples++; 
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25 } 

26 boolean failed = checkFinishId(tuple, TupleType.REGULAR) ; 
27 if(failed) { 

28 _delegate.fail(tuple) ; 

29 } else { 

30 _delegate.ack(tuple) ; 

31 } 

32 } 

33 

34 public void fail(Tuple tuple) { 

35 Object id = tuple.getValue(0); 

36 synchronized(_tracked) { 

37 TrackingInfo track = _tracked.get(id); 

38 if (track != null) 

39 track.failed = true; 

40 } 

41 checkFinishId(tuple, TupleType.REGULAR) ; 

42 _delegate.fail(tuple) ; 

43 } 

44 

45 public void reportError(Throwable error) { 

46 _delegate.reportError (error) ; 

47 } 

48 

49 

50 private void updateTaskCounts(Object id, List<Integer> tasks) { 
51 synchronized(_tracked) { 

52 TrackingInfo track = _tracked.get(id); 

53 if (track != null) { 

54 Map<Integer, Integer> taskEmittedTuples = track.taskEmittedTuples; 
55 for(Integer task: tasks) { 

56 int newCount = get(taskEmittedTuples, task, 0) + 1; 
57 taskEmittedTuples.put(task, newCount) ; 

58 } 

59 } 

60 } 

61 } 

62 } 


O 第 2~6 行 定义 了 构造 函数 ， 需 要 传人 所 代理 的 输出 收集 器 。Storm 中 采用 了 较 多 的 装饰 模 
式 , 最 基本 的 输出 收集 右 均 是 在 executor.clj 中 定义 的 , 然后 因为 可 以 在 其 基础 上 进行 定制 
并 添加 功能 。 

O 第 8~12 行 定义 了 emit 方 法 。 由 于 该 类 是 coordinatedBolt 的 一 个 内 部 类 ， 所 以 它 可 以 访问 
CoordinatedBolt 中 的 类 成 员 变 量 。 tracked 是 CoordinatedBolt 定 义 的 成 员 变 量 ， 在 事务 
Topology 中 ， 用 于 跟踪 每 一 个 事务 尝试 在 这 个 Bolt 上 的 处 理 情况 。 该 方法 除了 进行 正常 的 
消息 发 送 外 ， 还 会 更 新 发 送 到 每 一 个 目标 节点 的 消息 数目 的 。 

O 第 19~32 行 定义 ack 方 法 ， 并 且 统 计 已 经 收 到 的 消息 数目 ， 其 中 会 调用 checkFinishId 方 法 
检测 当前 事务 是 否 已 经 失败 , 然后 调用 代理 类 的 Ack 或 者 Fail 方 法 。 通 常 , CoordinatedBolt 
会 被 BatchBoltExecutor 类 包装 ， 后 者 的 execute 方 法 会 对 输入 的 消息 进行 Ack 操 作 ， 于 是 
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本 类 中 的 ack 方 法 将 被 调用 ， 故 可 在 此 处 统计 收 到 的 消息 数目 。 
口 第 34~43 行 定义 了 fail] 方 法 ， 它 将 TrackingInfo 数 据 标记 为 失败 。 
口 第 50~61 行 实现 了 更 新 已 经 发 送 的 消息 数目 的 方法 。 
在 Storm 的 Ack 框 架 下 , 最 终 的 Fail 和 Ack 消 息 会 传送 到 Spout 节 点 ,而 Spout 节 点 会 随即 调用 其 
Ack 或 者 Fail 方 法 ,然后 用 户 的 逻辑 便 知 道 了 是 否 该 重 传 或 者 产生 下 一 条 消息 。 中 间 的 Bolt 节 点 并 
不 会 重 传 任 何 消息 。 这 也 简化 了 Storm 的 消息 管理 。 


15.4.3 “CoordinatedBolt 中 的 消息 类 型 


CoordinatedBolt 主 要 处 理 的 3 种 消息 类 型 如 下 。 
口 REGULAR: 正常 的 数据 消息 。 
OID: 从 协调 Spout 节 点 收 到 的 事务 提交 消息 。 
T COORD: 其 他 的 CoordinatedBolt 收 到 的 协调 消息 。 

CoordinatedBolt 会 根据 输入 消息 的 流 号 来 对 消息 的 类 型 进行 判断 。Topology 构 建 器 会 将 实现 
了 ICommitter 的 Bolt 中 的 _idstreamSpec 设 为 协调 Spout 节 点 的 事务 提交 流 。 其 他 情况 下 ， 
_idstreamspec 的 值 为 空 。 如 果 消 息 来 自 协调 消息 流 ， 则 认为 消息 的 类 型 为 协调 消息 类 型 COORD , 
其 他 情况 下 默认 为 REGULAR 类 型 。 

目前 ，Storm 还 不 存在 一 种 机 制 能 禁止 用 户 向 系统 的 流 中 写 和 人 数据。 显而易见 ， 如 果 写 入 的 
话 ， 将 会 产生 很 多 莫名其妙 的 错误 。 

消息 的 类 型 定义 及 判定 方法 如 下 面 的 代码 所 示 : 


static enum TupleType { 
REGULAR, 
ID， 
COORD 

} 


private TupleType getTupleType(Tuple tuple) { 
if( idStreamSpec!-null 
&& tuple.getSourceGlobalStreamid().equals( idStreamSpec. id)) { 
return TupleType.ID; 
} else if(! sourceArgs.isEmpty() 
&& tuple.getSourceStreamId().equals(Constants.COORDINATED STREAM ID)) 1 
return TupleType.COORD; 
) else { 
return TupleType.REGULAR; 
) 
} 


1544 ”成 员 变量 以 及 主要 方法 分 析 


CoordinatedBolt 成 员 变 量 的 定义 如 下 : 
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priv 
priv 
priv 
priv 
priv 
priv 
priv 
口 
口 
口 
口 
口 
口 


口 


ate Map«String, SourceArgs»  sourceArgs; 
ate IdStreamSpec  idStreamSpec; 

ate IRichBolt delegate; 

ate Integer numSourceReports; 


ate List<Integer> _countOutTasks = new ArrayList<Integer>();; 


ate OutputCollector collector; 
ate TimeCacheMap<Object, TrackingInfo> _tracked; 


_sourceArgs: 用 来 表示 哪些 节点 将 向 该 Bolt 发 送 协调 


m 


的 处 理 情 况 。 它 是 TrackingInfo 类 的 对 象 。 


接 下 来 分 析 一 下 主要 的 实现 方法 。 首 先 ， 我 们 看 看 execute 方 法 的 实现 : 


p 


1 
2 
3 
4 
5 
6 
7 
8 
9 


ublic void execute(Tuple tuple) { 
Object id = tuple.getValue(0); 
TrackingInfo track; 
TupleType type - getTupleType(tuple); 
synchronized( tracked) { 
track = tracked.get(id); 
if(track--null) { 
track = new TrackingInfo(); 
if( idStreamSpec--null) track.receivedId - 
 tracked.put(id, track); 


} 


if(type--TupleType.ID) { 
synchronized(_tracked) { 
track.receivedId = true; 
} 


checkFinishId(tuple, type); 
} else if(type--TupleType.COORD) { 
int count = (Integer) tuple.getValue(1); 
synchronized(_tracked) { 
track. reportCount++; 
track.expectedTupleCount+=count; 
} 
checkFinishId(tuple, type); 
} else { 
synchronized(_tracked) { 
_delegate.execute(tuple) ; 


_idStreamSpec: 目前 用 来 表示 该 节点 是 否 是 事务 提交 节 节点 。 
_delegate: 内 含 实际 的 Bolt 逻 辑 。 
_numSourceReports: 表示 Bolt 的 上 游 节点 的 个 数 。 
.countOutTasks: 表示 将 向 哪些 Task 发 送 数据 。 
_collector: 可 以 统计 消息 发 送 和 接收 数目 的 输出 收集 融 。 
tracked: 用 来 保存 在 此 节点 中 正在 被 处 理 的 事务 尝 


W, 键 为 事务 尝 


true; 


试 消息 , 值 为 该 事务 
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a 第 4 行 计算 获得 输入 消息 的 消息 类 型 。 any 
O 第 5~12 行 从 第 1 列 得 到 消息 的 事务 尝试 消息 ， 然 后 将 其 作为 键 ， 若 该 事务 还 没有 被 跟踪 , 
则 开始 对 其 进行 跟踪 。 
O 在 第 9% 行 中 ， 如 果 _idstreamspec 为 空 ， 则 直接 将 receivedId 设 置 为 true， 即 在 非 习 
节点 中 会 这 样 设置 。 
a 第 14~18 行 表示 收 到 了 从 协调 Spout 发 送 过 来 的 事务 提交 消息 。 
口 第 19~25 行 表示 收 到 了 从 其 他 节点 发 送 过 来 的 协调 信息 ， 此 时 Storm 将 更 新 跟踪 信息 中 的 
reportCount 以 及 expectedTupleCount。 协 调 消 息 的 模式 为 <Id，Count>。 
口 第 26~29 行 处 理 普通 的 数据 消息 。 

在 处 理 控制 消息 时 ， 会 调用 checkFinishId 方 法 来 检测 该 节点 是 否 完 成 了 对 事务 的 处 理 ， 进 
而 决定 是 否 可 以 调用 finishBatch 方 法 以 及 是 否 可 以 向 其 下 游 节 点 发 送 协调 消息 等 。 
checkFinishId 方 法 的 分 析 如 下 ， 该 方法 是 CoordinatedBolt 的 核心 ， 理 解 其 实现 细节 至 关 重 要 


R 
d 
E 


1 private boolean checkFinishId(Tuple tup, TupleType type) { 

2 Object id = tup.getValue(0); 

3 boolean failed - false; 

4 

5 synchronized( tracked) { 

6 TrackingInfo track = tracked.get(id); 

7 try { 

8 if(track!=null) { 

9 boolean delayed = false; 

10 if( idStreamSpec--null && type == TupleType.COORD || _idStreamSpec!=null && 
type--TupleType.ID) { 

11 track.ackTuples.add(tup) ; 

12 delayed = true; 

13 

14 if(track.failed) { 

15 failed = true; 

16 for(Tuple t: track.ackTuples) { 

17 _collector.fail(t); 

18 

19 _tracked.remove(id) ; 

20 ) else if(track.receivedId 

21 && ( sourceArgs.isEmpty() || 

22 track.reportCount-- numSourceReports 88 

23 track.expectedTupleCount == track.receivedTuples))[ 

24 if( delegate instanceof FinishedCallback) { 

25 ((FinishedCallback) delegate).finishedId(id); 

26 

27 if(!( sourceArgs.isEmpty() || type!-TupleType.REGULAR)) { 

28 throw new IllegalStateException("Coordination condition met 

on a non-coordinatingtuple. Should be impossible"); 

29 } 

30 Iterator<Integer> outTasks = _countOutTasks.iterator(); 

31 while(outTasks.hasNext()) { 

32 int task = outTasks.next(); 


33 int numTuples = get(track.taskEmittedTuples, task, 0); 
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34 _collector.emitDirect(task, Constants.COORDINATED STREAM ID, tup, new 
Values(id,numTuples)); 

35 } 

36 for(Tuple t: track.ackTuples) { 

37 _collector.ack(t); 

38 } 

39 track.finished = true; 

40 _tracked.remove(id) ; 

41 } 

42 if(!delayed 8& type!=TupleType.REGULAR) { 

43 if(track.failed) { 

44 _collector.fail(tup) ; 

45 } else { 

46 . collector.ack(tup); 

47 } 

48 } 

49 } else { 

50 if(type!=TupleType.REGULAR) collector. fail(tup); 

51 

52 } catch(FailedException e) { 

53 LOG.error("Failed to finish batch", e); 

54 for(Tuple t: track.ackTuples) { 

55 _collector.fail(t); 

56 

57 _tracked.remove(id) ; 

58 failed = true; 

59 } 

60 } 

61 return failed; 

62 } 


后 统一 进行 Ack 操 作 ， 或 者 在 事务 处 理 失 败 后 统一 进行 Fail 操 作 。 
a 在 第 14~19 行 中 ， 当 认为 事务 已 经 失败 时 ， 将 对 收 到 的 控制 消息 
答 试 从 跟踪 列表 中 去 掉 。 

O 在 第 20~41 行 中 ， 判 断 事务 是 否 已 经 处 理 结束 并 进行 相应 的 处 理 


O 在 第 10~13 行 中 , 如果 收 到 了 控制 消息 , 则 将 其 放 入 变量 ackTuples 中 , 并 在 事务 处 理 结 


进行 Fail 操 作 ， 并 将 该 事 


。 第 20~23 行 用 来 判断 是 


否 已 经 完成 了 对 事务 的 处 理 ， 具 体 条 件 如 下 。 当 满足 这 些 条 件 时 ， 表 示 该 节点 已 经 收 全 
一 个 事务 的 所 有 消息 ， 可 以 对 事务 进行 后 处 理 了 。 这 是 一 个 非常 关键 的 时 间 点 。 


提交 消息 。 若 为 非 事务 提交 Bolt 节 点 ， 该 条 件 默认 为 tue。 


a 第 20 行 的 条 件 的 含义 为 : 若 为 事务 提交 Bolt 节 点 ， 并 且 收 到 了 从 协调 Spout 发 送 来 的 事务 


O 第 21~23 行 条 件 的 含义 为 : 该 节点 没有 协调 消息 输入 , 或 者 该 节点 的 消息 源 均 向 该 节点 发 


送 了 协调 消息 。 系 统 中 的 协调 Spout 节 点 并 不 适合 用 CoordinatedBolt 进 行 封装 ， 所 以 事务 


Topology 中 的 消息 发 送 节点 为 最 开始 的 CoordinatedBolt 节 点 ， 耻 


了 没有 其 他 节点 会 向 其 发 


送 协 调 消 息 了 。 但 是 消息 发 送 节点 只 从 协调 Spout 接 收 消息 ,一 条 消息 即 表 示 一 个 事务 ， 
因此 其 处 理 较为 简单 ， 当 其 收 到 一 条 消息 后 即 认为 已 经 收 到 了 属于 该 事务 的 全 部 消息 ， 


并 且 满 足 向 下 游 节点 发 送 协调 消息 的 条 件 。 
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a 在 第 24~26 行 中 ， 如 果 用 户 的 Bolt 实 现 了 FinishedCallback 接 口 ， 此 时 将 调用 其 finishId 
方法 ， 即 用 户 的 finishBatch 方 法 。 此 时 ,保证 了 Storm 已 经 接收 到 了 属于 该 事务 的 所 有 消 
息 ， 于 是 可 以 调用 finishBatch 来 对 事务 进行 后 处 理 。 用 户 在 实现 IBatchBolt 时 ， 需 要 实 
现 finishBatch 方 法 。CoordinatedBolt 保 证 一 个 Bolt 节 点 收 全 了 一 个 事务 的 所 有 消息 后 ， 
finishBatch 方 法 才 会 被 调用 。 实际 上 , CoordinatedBolt 可 以 用 在 非 事 务 的 批 处 理 环境 下 。 

a 在 第 27~29 行 中 ， 若 收 到 的 消息 为 普通 的 消息 ， 但 是 该 Bolt 此 时 已 经 认为 收 到 了 所 有 的 数 

据 ， 那 么 就 进入 了 异常 状态 。 

口 第 30~35 行 用 于 向 下 游 的 节点 发 送 协调 消息 ,， 这样 下 游 节 点 便 可 以 用 来 判断 事务 是 否 可 以 
结束 。 此 时 ， 整 个 Topology 就 通过 协调 消息 串联 了 起 来 。 注 意 第 34 行 在 调用 emitDirect 方 
法 时 以 tup 为 标记 ， 这 也 表示 对 该 控制 消息 进行 跟踪 。 

口 第 36~38 行 用 于 对 所 有 的 控制 消息 进行 Ack 操 作 。 

a 第 42~48 行 作者 认为 是 不 需要 的 。delayed 变 量 的 默认 值 为 false， 并 且 只 有 当 收 到 控制 消息 
时 才 会 被 设置 为 true。 而 在 这 段 代码 中 ， 要 求 收 到 的 消息 为 控制 信息 ， 同 时 变量 delayed 为 
false， 这 是 不 能 到 达 的 。 此 外 ， 如 果 前 面 已 经 对 控制 信息 进行 了 Ack 或 Fail 操 作 , 那么 再 进 
行 该 种 操作 也 会 导致 Storm 的 Ack 系 统 出 现 问题 。Storm 在 Trident 的 实现 中 对 其 进行 了 更 正和 
优化 。 

O 第 52~58 行 是 异常 处 理 ， 进 行 与 第 14~19 行 相 类 似 的 操作 。 

目前 ， 我 们 分 析 了 CoordinatedBolt 中 的 大 部 分 实现 ， 其 余 代 码 与 Topology 的 静态 结构 有 关 ， 
即 一 个 Bolt 将 从 哪些 Bolt 接 收 协调 数据 , 并 向 哪些 Bolt 发 送 协调 数据 , 这 将 在 15.7 节 中 进一步 讨论 。 

CoordinatedBolt 是 事务 Topology 的 核心 http://xumingming.sinaapp.com/811 /twitter-storm- 
code-analysis-coordinated-bolt/ 包 含 了 一 些 额 外 的 分 析 。Storm 项 目的 作者 对 此 也 有 一 些 想法 , 具体 

请 参考 如 下 链接 : https://github.com/nathanmarz/storm/issues/118。 


15.5 ”分 区 的 事务 类 型 


分 区 的 事务 类 型 是 对 事务 处 理 的 进一步 抽象 ， 它 可 以 认为 是 提供 给 用 户 的 事务 类 型 ，Storm 
平台 本 身 并 不 识别 这 种 类 型 , 而 是 通过 将 其 适 配 为 系统 中 的 默认 事务 类 型 。 故 其 接口 与 前 面 介 绍 
的 有 很 大 不 同 ,而 Storm 通 过 工具 类 将 这 些 接口 适 配 为 ItransactionalSpout 接 口 。 这 是 Storm 中 常 
用 的 技巧 , 它 简 化 了 平台 的 设计 ,同时 为 平台 提供 了 极 大 的 扩展 性 。 该 技巧 的 模式 为 首先 定义 一 
个 接口 ， 然 后 通过 一 个 执行 类 进行 接口 的 适 配 。 

本 节 首 先 介 绍 分 区 事务 类 型 的 接口 ， 然 后 介绍 其 适 配 执行 类 。 


15.5.1 分 区 的 事务 Spout 接 口 


分 区 的 事务 的 Spout 是 对 基础 事务 的 Spout 的 进一步 抽象 ， 用 户 可 以 通过 它 来 完成 对 事务 数据 
的 分 区 处 理 。 
首先 ， 我 们 先 来 看 一 下 IPartitionedTransactionalSpout 接 口 的 定义 及 分 析 : 
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public interface IPartitionedTransactionalSpout<T> extends IComponent { 
public interface Coordinator { 

/** 
* Return the number of partitions currently in the source of data. The idea is 
* is that if a new partition is added and a prior transaction is replayed, it doesn't 
* emit tuples for the new partition because it knows how many partitions were in 

* that transaction. 

*/ 

int numPartitions(); 


/** 


* Returns true if its ok to emit start a new transaction, false otherwise (will skip 
thistransaction). 
* 


* You should sleep here if you want a delay between asking for the next transaction (this willbe 
called 
* repeatedly in a loop). 
*/ 
boolean isReady(); 


void close(); 


} 


public interface Emitter<X> { 
/** 


* Emit a batch of tuples for a partition/transaction that's never been emitted before. 
* Return the metadata that can be used to reconstruct this partition/batch in the future. 
g 
X emitPartitionBatchNew(TransactionAttempt tx, BatchOutputCollector collector, int partition, 
X lastPartitionMeta); 


/** 


* Emit a batch of tuples for a partition/transaction that has been emitted before, using 
* the metadata created when it was first emitted. 
"f 
void emitPartitionBatch(TransactionAttempt tx, BatchOutputCollector collector, int partition, 
X partitionMeta); 
void close(); 


} 


Coordinator getCoordinator(Map conf, TopologyContext context); 
Emitter<T> getEmitter(Map conf, TopologyContext context); 
} 


这 个 接口 与 ITransactionalSpout 接 口 有 很 大 的 不 同 ， 代 表 了 另外 一 种 抽象 方式 ， 它 在 协调 
Spout 中 储存 的 关于 事务 的 元 信息 是 每 个 事务 所 含 分 区 的 数目 。 每 一 个 事务 中 与 各 个 分 区 相关 的 
元 数据 由 emitPartitionBatchNew 方 法 指定 , 该 方法 是 在 消息 发 送 节 点 上 被 调用 的 。 下 面 简 要 介绍 
该 接口 中 涉及 的 几 个 方法 。 

O numpPartitions 方 法 会 在 ITransactionalSpout.initializeTransaction 方 法 中 调用 , 返回 每 

一 个 事务 所 包含 的 分 区 数目 。 
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口 isReady 方 法 与 ITransactionalSpout.isReady 方 法 的 含义 相同 ， 表 示 数 据 是 否 已 经 准备 好 

以 便 开 始 一 个 新 的 事务 。 

口 emitPartitionBatchNew7; i4; LA /& emitPartitionBatch7; 1A; FE ITransactionalSpout.emit 
Batch 中 被 调用 。emitPartitionBatchNew 方 法 会 在 一 个 事务 首次 进行 尝试 时 被 调用 ， 它 会 
基于 当前 分 区 以 及 事务 ， 计 算 获得 该 分 区 所 对 应 的 元 数据 。 

O emitpPartitionBatch 会 在 重 传 时 被 调用 。 当 然 ， 在 具体 的 实现 中 ，emitpPartitionBatchNew 

方法 可 以 基于 emitpPartitionBatch 方 法 来 实现 。 区 别 在 于 ，emitpPartitionBatch 方 法 知道 

该 分 区 在 当前 事务 上 面 的 元 数据 是 什么 ， 而 emitpPartitionBatchNew 则 需要 通过 计算 来 得 

到 该 元 数据 。 
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PartitionedTransactionalSpoutExecutor 类 实现 了 ITransactionalSpout 接 口 ， 请 注意 它 的 元 
数据 的 类 型 为 Integer 类 型 ， 表 示 分 区 数目 。 

这 个 类 实现 可 以 被 认为 是 学 习 接口 ITransactionalSpout 及 事务 Topology 的 一 个 实例 。 

partitionedTransactionalSpoutExecutor 中 含有 一 个 IPartitionedTransactionalSpout 的 代 
理 _spout 成 员 变 量 ，ITransactionalSpout 中 定义 的 方法 将 通过 调用 _spout 中 相应 的 方法 来 实现 。 
该 类 的 实现 代码 如 下 : 


public class PartitionedTransactionalSpoutExecutor implements ITransactionalSpout<Integer> { 
IPartitionedTransactionalSpout _spout; 


public PartitionedTransactionalSpoutExecutor(IPartitionedTransactionalSpout spout) { 
_spout = spout; 
} 


public IPartitionedTransactionalSpout getPartitionedSpout() { 
return spout; 
} 


@Override 

public ITransactionalSpout.Coordinator getCoordinator(Map conf, TopologyContext context) { 
return new Coordinator(conf, context); 

} 


@Override 

public ITransactionalSpout.Emitter getEmitter(Map conf, TopologyContext context) { 
return new Emitter(conf, context); 

} 


@Override 

public void declareOutputFields(OutputFieldsDeclarer declarer) { 
Spout.declareOutputFields(declarer); 

} 
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@Override 

public Map<String, Object> getComponentConfiguration() { 
return _spout.getComponentConfiguration() ; 

} 


} 
接 下 来 讨论 协调 Spout 的 相关 接口 的 实现 如 下 : 


1 class Coordinator implements ITransactionalSpout.Coordinator<Integer> { 


2 private IPartitionedTransactionalSpout.Coordinator coordinator; 
3 

4 public Coordinator(Map conf, TopologyContext context) { 
5 coordinator = _spout.getCoordinator(conf, context); 
6 } 

7 

8 @Override 

9 public Integer initializeTransaction(BigInteger txid, Integer prevMetadata) { 
10 return coordinator.numPartitions(); 

11 } 

12 

13 (QOverride 

14 public boolean isReady() { 

15 return coordinator.isReady(); 

16 ) 

17 

18 @Override 

19 public void close() { 

20 _coordinator.close(); 

21 } 

22 } 


a 第 4~6 行 在 构造 函数 中 得 到 IPartitionedTransactionalSpout.Coordinator。 

a 第 9~11 行 实现 initializeTransaction 方 法 ， 它 将 返回 分 区 的 数目 。 

a 第 14~16 行 实现 isReady 方 法 ， 调 用 _coordinator 对 象 的 jsReady 方 法 。 在 协调 Spout 中 ， 当 
产生 新 的 事务 尝试 时 ， 会 将 其 对 应 分 区 的 数目 作为 元 数据 。 

下 面 来 看 消息 发 送 节 点 及 相关 接口 的 实现 ， 相 关 代码 如 下 : 


1 class Emitter implements ITransactionalSpout.Emitter«Integer» { 

2 private IPartitionedTransactionalSpout.Emitter emitter; 

3 private TransactionalState state; 

4 private Map«Integer, RotatingTransactionalState» partitionStates = new HashMap«Integer, 
RotatingTransactionalState»(); 

private int index; 

private int numTasks; 


public Emitter(Map conf, TopologyContext context) { 
emitter = _spout.getEmitter(conf, context); 
10 _state = TransactionalState.newUserState(conf, (String) 
conf.get(Config.TOPOLOGY TRANSACTIONAL ID), getComponentConfiguration()); 
11 _index =context. getThisTaskIndex(); 
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12 _numTasks = context.getComponentTasks (context.getThisComponentId()).size(); 

13 ] 

14 

15 @Override 

16 public void emitBatch(final TransactionAttempt tx, final Integer partitions, 

17 final BatchOutputCollector collector) { 

18 for(int i= index; i < partitions; i+=_numTasks) { 

19 if(!_partitionStates.containsKey(i)) { 

20 _partitionStates.put(i, new RotatingTransactionalState(_state, "" + i)); 

21 } 

22 RotatingTransactionalState state = _partitionStates.get(i); 

23 final int partition = i; 

24 Object meta = state.getStateOrCreate(tx.getTransactionId(), 

25 new RotatingTransactionalState.StateInitializer() { 

26 @Override 

27 public Object init(BigInteger txid, Object lastState) { 

28 return emitter.emitPartitionBatchNew(tx, collector, partition, lastState); 

29 } 

30 1 

31 // it's null if one of: 

32 //a) a later transaction batch was emitted before this, so we should skip this batch 

33 //b) if didn't exist and was created (in which case the StateInitializer 
was invoked and 

34 // it was emitted 

35 if(meta!-null) { 

36  emitter.emitPartitionBatch(tx, collector, partition, meta); 

37 } 

38 } 

39 } 

40 

41 @Override 

42 public void cleanupBefore(BigInteger txid) { 

43 for(RotatingTransactionalState state: _partitionStates.values()) ( 

44 state.cleanupBefore(txid); 

45 } 

46 } 

47 


48 @Override 
49 public void close() { 


50 _state.close(); 
51 _emitter.close(); 
52 } 

53 } 


O 第 3 行 定义 的 _state 为 TransactionalState 类 型 ， 它 所 对 应 的 数据 被 放 在 user 子 目录 下 。 根 
据 前 面 的 讨论 ， 协 调 Spout 节 点 所 对 应 的 元 数据 存放 在 coordinator 子 目录 下 。 此 处 的 目录 
是 指 ZooKeeper 中 的 路 径 。 

口 第 4 行 中 的 _partitionStates 为 一 个 哈 希 表 ， 每 个 分 区 都 对 应 了 一 个 RotatingTransactional 
State 对 象 。 注 意 在 初始 化 RotatingTransactionalState 时 ， 并 不 要 求 进 行事 务 元 数据 的 强 序 
检查 。 假设 我 们 有 两 个 分 区 P; 和 P>， 目 前 有 两 个 活跃 的 事务 序号 为 txidj 和 txid， 且 Topology 
中 SpoutId 为 SPOUT， 那 么 在 运行 过 程 中 将 会 产生 如 下 的 目录 结构 : 
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/transactional/SPOUT/coordinator/txid, 
/transactional/SPOUT/coordinator/txid, 
/transactional/SPOUT/user/P,/txid, 
/transactional/SPOUT/user/P,/txid, 
/transactional/SPOUT/user/P;/txid; 
/transactional/SPOUT/user/P,/txid, 


即 每 个 分 区 都 会 对 应 同样 的 事务 序列 ， 分 区 P; 和 P: 都 同样 含有 txidi 和 txid 事 务 序列 。 仔 细 

揣摩 分 区 与 事务 的 对 应 关系 是 理解 这 个 类 的 关键 。 

O 第 5 行 定 义 的 _index 表 示 当 前 消息 发 送 节 点 在 所 有 消息 发 送 节 点 中 的 索引 ， 它 是 从 0 开始 
的 。 例 如 ， 消 息 发 送 节 点 的 并 行 度 为 10， 那 么 系统 中 将 存在 10 个 消息 发 送 节 点 ， 每 个 节 
点 都 会 被 唯一 地 赋予 一 个 0~9 之 间 的 标号 来 进行 区 分 。TaskId 是 Topology 给 所 有 Task 赋 予 
的 编号 ， 即 便 Task 重 启 这 个 编号 也 不 会 改变 。 而 _index 索 引 实际 上 是 基于 TaskId 的 ， 因 此 
_index 号 码 也 是 稳定 的 ， 它 可 通过 调用 getComponentTasks 方 法 获得 。 

口 第 6 行 定 义 的 _numTasks 表 示 消 息 发 送 节 点 的 并 行 度 。 

a 第 16~39 行 是 emitBatch 方 法 的 实现 , 它 将 会 调用 emitpPartitionBatchNew 以 及 emitPartitionBatch 

方法 。 

a 第 18 行 在 消息 发 送 节 点 上 对 分 区 进行 分 配 。 例 如 ， 有 10 个 分 区 ， 以 及 2 个 节点 Eo。、E1， 那 
么 Eo 将 处 理 P。、P，,，、P4、P6、Ps， 而 Es 将 处 理 P!|、P3、P;、P7、Po。， 其 中 Pi 代表 第 i 个 分 区 。 
于 是 ， 当 分 区 数目 小 于 消息 发 送 节点 的 数目 时 ， 将 有 一 部 分 节点 处 于 空闲 状态 。 

O 在 第 19~21 行 中 , 若 分 区 所 对 应 的 RotatingTransactionalState 对 象 不 存在 , 则 创建 该 对 象 。 

在 ZooKkeeper 中 ， 子 目录 为 分 区 的 编号 。 

a 第 24~30 行 用 于 为 当前 的 分 区 创建 元 数据 。getSstate0rCreate 方 法 的 第 二 个 参数 需要 传人 
一 个 实现 了 接口 stateInitializer 的 对 象 。 第 25~29 行 定义 了 一 个 内 部 类 并 将 其 作为 参数 
传人 。 这 里 的 init 方 法 将 调用 emitpPartitionBatchNew 方 法 , 可 以 保证 它 只 有 在 处 理 新 事务 
时 才 会 被 调用 。 
getState0TCTeate 方 法 在 以 下 两 种 情况 下 可 能 返回 空 。 
mu 新 的 事务 已 被 初始 化 并 通过 emitPartitionBatchNew 方 法 发 送出 去 。 

m 比 当前 事务 更 大 的 事务 已 经 被 发 送出 去 了 ， 并 且 该 事务 是 基于 当前 事务 前 面 的 事务 产 

生 的 ， 于 是 我 们 需要 忽略 当前 的 事务 ， 详 情 请 参考 4.5 节 。 

当 返 回 的 元 数据 不 为 空 时 ， 将 调用 emitpartitionBatch 方 法 ， 表 示 对 当前 事务 进行 重 传 。 
口 第 42~46 行 定义 了 cleanupBefore 方 法 ， 它 会 根据 已 经 提交 的 事务 序号 对 元 数据 进行 清理 。 
由 于 不 同 的 消息 发 送 节点 所 负责 的 事务 分 区 是 不 同 的 ， 因 此 它们 对 ZooKeeper 的 数据 操作 是 
没有 冲突 的 。 通 过 这 个 类 的 实现 可 以 得 知 ， 并 不 仅仅 是 协调 Spout 节 点 可 以 产生 和 维护 元 数据 ， 
如 果 设 计 合理 ，Bolt 端 同样 也 可 以 完成 类 似 的 事情 。 
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目前 ，Storm 只 支持 具有 分 区 功能 的 模糊 事务 类 型 的 Spout， 它 们 主要 用 于 读 取 Kafka 队 列 中 
的 数据 ， 该 类 型 也 是 系统 中 最 复杂 的 Spout 类 型 。 其 实现 技术 与 分 区 的 基本 事务 的 Spout 相 似 : 先 
定义 一 个 用 户 接口 ， 然 后 再 定义 一 个 类 进行 接口 适 配 并 执行 。 


15.6.1 分 区 的 模糊 事务 Spout 的 接口 


接口 I0paquepPartitionedTransactionalSpout 与 ITransactionalSpout 的 区 别 也 较 大 , 它 实际 上 
并 不 会 在 协调 Spout 中 存储 任何 元 数据 ， 其 代码 如 下 : 


public interface IOpaquePartitionedTransactionalSpout«T» extends IComponent { 
public interface Coordinator { 
/** 
* Returns true if its ok to emit start a new transaction, false otherwise (will skip this 
transaction). 
* 
* You should sleep here if you want a delay between asking for the next transaction (this will 
be called 
* repeatedly in a loop). 
sf 
boolean isReady(); 
void close(); 


} 


public interface Emitter«X» { 

/** 

* Emit a batch of tuples for a partition/transaction. 

* 

* Return the metadata describing this batch that will be used as lastPartitionMeta 
* for defining the parameters of the next batch. 

*/ 

X emitPartitionBatch(TransactionAttempt tx, BatchOutputCollector collector, int partition, X 

lastPartitionMeta); 
int numPartitions(); 
void close(); 


} 


Emitter<T> getEmitter(Map conf, TopologyContext context); 
Coordinator getCoordinator(Map conf, TopologyContext context); 


} 

协调 Spout 接 口中 只 定义 了 isReady 方 法 ， 用 于 表示 数据 源 否 准备 好 以 及 是 否 开 始 一 个 新 的 事务 。 

相 比 于 IPartitionedTransactionalSpout 接 口 ，I0paquePartitionedTransactionalSspout 接 口中 
numParitions 方 法 被 放 和 人 了 Emitter 接 口 里 面 。 

emitPartitionBatch 的 参数 列表 与 IPartitionedTransactionalSpout 中 的 emitPartition 


BatchNew 方 法 很 类 似 。 
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15.6.2 ”模糊 的 事务 Spout 执 行 器 


OpaquePartitionedTransactionalSpoutExecutor 类 实现 了 ICommitterTransactionalSpout 接 


A, ， 该 接口 继承 自 ITransactionalSpout 接 口 ， 并 添加 了 commit 接 口 方法 。 该 类 的 消息 发 送 接口 较 
为 复杂 ， 本 文 将 对 其 进行 单独 分 析 。 
0paquePartitionedTransactionalSpoutExecutor 类 的 实现 代码 如 下 : 


1 public class OpaquePartitionedTransactionalSpoutExecutor implements ICommitterTransactionalSpout 
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37 
38 


<Object> { 
IOpaquePartitionedTransactionalSpout _ spout; 


public class Coordinator implements ITransactionalSpout.Coordinator«Object» { 


IOpaquePartitionedTransactionalSpout.Coordinator coordinator; 


public Coordinator(Map conf, TopologyContext context) { 
coordinator = _spout.getCoordinator(conf, context); 
} 


(QOverride 

public Object initializeTransaction(BigInteger txid, Object prevMetadata) { 
return null; 

} 


(QOverride 
public boolean isReady() { 

return coordinator.isReady(); 
} 


(QOverride 

public void close() ( 
_coordinator.close(); 

} 


public OpaquePartitionedTransactionalSpoutExecutor(IOpaquePartitionedTransactional Spout 


spout) { 
_spout = spout; 


@Override 
public ITransactionalSpout.Coordinator<Object> getCoordinator(Map conf, Topology Context 


context) { 
return new Coordinator(conf, context); 


@Override 
public ICommitterTransactionalSpout.Emitter getEmitter(Map conf, TopologyContext context) { 


return new Emitter(conf, context); 
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42 @Override 

43 public void declareOutputFields(OutputFieldsDeclarer declarer) { 
44 _spout.declareOutputFields (declarer); 

45 } 

46 

47 @Override 

48 public Map<String, Object> getComponentConfiguration() { 

49 return spout.getComponentConfiguration(); 

50 ) 

51 } 


O 第 1 行 说 明 该 类 实现 了 ICommitterTransactionalSpout 接 口 ,表明 在 消息 发 送 节 点 中 需要 实 

现 commit 回 调 方法 。 

a 第 12~14 行 定义 的 initializeTransaction 方 法 的 返回 值 为 空 ,表示 在 协调 Spout 中 不 存储 任 
何 元 数据 。 其 他 方法 都 是 比较 直观 的 ， 读 者 可 自行 分 析 。 

下 面 主 要 分 析 其 消息 发 送 接口 的 实现 ， 相 关 代码 如 下 : 


1 public class Emitter implements ICommitterTransactionalSpout.Emitter { 

2 IOpaquePartitionedTransactionalSpout.Emitter emitter; 

3 TransactionalState state; 

4 TreeMap«BigInteger, Map«Integer, Object»»  cachedMetas - new TreeMap«BigInteger, 
Map«Integer ,Object>>(); 


5 Map«Integer, RotatingTransactionalState>  partitionStates = new HashMap<Integer, 
RotatingTransactionalState»(); 

6 int index; 

7 int numTasks; 

8 

9 public Emitter(Map conf, TopologyContext context) { 

10 emitter = spout.getEmitter(conf, context); 

11 _index = context.getThisTaskIndex(); 

12 _numTasks = context.getComponentTasks (context.getThisComponentId()).size(); 

13 _state = TransactionalState.newUserState(conf, (String) conf.get(Config.TOPOLOGY_ 

TRANSACTIONAL ID), getComponentConfiguration()); 

14 List<String> existingPartitions = state.list(""); 

15 for(String p: existingPartitions) { 

16 int partition - Integer.parseInt(p); 

17 if((partition - index) % numTasks == 0) { 

18  partitionStates.put(partition, new RotatingTransactionalState( state, p)); 

19 } 

20 } 

21 } 

22 

23 @Override 


24 public void emitBatch(TransactionAttempt tx, Object coordinatorMeta, BatchOutputCollector 
collector) { 


25 Map<Integer, Object> metas = new HashMap<Integer, Object>(); 

26 _cachedMetas.put(tx.getTransactionId(), metas); 

27 int partitions = _emitter.numPartitions(); 

28 Entry<BigInteger, Map«Integer, Object>> entry = _cachedMetas.lowerEntry 


(tx. getTransactionId()); 
29 Map<Integer, Object> prevCached; 
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30 if(entry!=null) { 

31 prevCached = entry.getValue(); 

32 } else { 

33 prevCached = new HashMap<Integer, Object>(); 

34 } 

35 

36 for(int i=_index; i « partitions; i+=_numTasks) { 

37 RotatingTransactionalState state = _partitionStates.get(i); 
38 if(state==null) { 

39 state = new RotatingTransactionalState(_state, "" + i); 
40 _partitionStates.put(i, state); 

41 } 

42 state.removeState(tx.getTransactionId()); 

43 Object lastMeta - prevCached.get(i); 

44 if(lastMeta--null) lastMeta = state.getLastState(); 

45 Object meta = _emitter.emitPartitionBatch(tx, collector, i, lastMeta); 
46 metas.put(i, meta); 

47 } 

48 } 

49 

50 @Override 

51 public void cleanupBefore(BigInteger txid) { 

52 for(RotatingTransactionalState state: _partitionStates.values()) { 
53 state.cleanupBefore(txid) ; 

54 } 

55 } 

56 

57 (QOverride 

58 public void commit(TransactionAttempt attempt) { 

59 BigInteger txid - attempt.getTransactionId(); 

60 Map«Integer, Object» metas = _cachedMetas.remove(txid) ; 

61 for(Integer partition: metas.keySet()) ( 

62 Object meta - metas.get(partition); 

63  partitionStates.get(partition).overrideState(txid, meta); 
64 } 

65 } 

66 


67 @Override 

68 public void close() { 

69 _emitter.close(); 

70 } 

71 } 

在 这 个 类 中 ， 我 们 需要 重点 理解 的 是 分 区 的 元 数据 的 产生 及 更 新 。 

O 第 4 行 定义 了 类 成 员 变 量 _ cachedMetas， 它 的 键 为 事务 序号 ， 值 同样 也 是 一 个 哈 希 表 。 该 
哈 希 表 的 键 为 分 区 号 ， 值 为 此 分 区 的 元 数据 ， 即 总 的 映射 关系 为 事务 序号 -> 分 区 号 -> 分 
区 元 数据 。 

a 第 9~21 行 定义 了 消息 发 送 节点 的 构造 方法 。 第 15~20 行 将 已 经 存放 在 ZooKeeper 中 的 数据 
加 载 到 _partitionstates 成 员 变量 中 。 第 17 行 与 第 36 行 计算 得 到 的 分 区 与 节点 的 对 应 关系 
是 相同 的 ， 当 Topology 启 动 后 ， 哪 些 Emitter 节 点 处 理 哪些 分 区 是 固定 的 。 


15.7 事务 Topology 的 构建 器 281 


口 第 24~48 行 实现 了 emitBatch 方 法 。 这 里 并 不 会 去 区 分 事务 究竟 是 新 事务 还 是 重 传 事务 。 
口 第 25 行 定义 了 一 个 全 新 的 哈 希 表 类 型 的 元 数据 对 象 ， 用 来 存储 当前 事务 下 每 个 分 区 所 对 
应 的 元 数据 。 

口 第 27 行 调用 numPartitions 方 法 获得 当前 的 分 区 数目 。 

口 第 28~34 行 试图 获取 前 一 个 事务 所 对 应 的 元 数据 。 

O 第 36~47 行 对 当前 消息 发 送 节 点 上 的 每 一 个 分 区 进行 处 理 。 第 42 行 将 ZooKeeper 中 的 数据 

清理 掉 ， 表 示 当 前 事务 正在 被 处 理 。 

口 第 45 行 调用 emitpartitionBatch 方 法 ， 并 将 该 分 区 所 对 应 的 数据 放 于 元 数据 中 。 值 得 注意 
的 是 ,在 emitBatch 方 法 中 ,分 区 所 对 应 的 元 数据 并 没有 被 写 回 到 ZooKeeper 中 ,它们 在 调 
用 commit 方 法 时 被 写 回 。 

口 第 58~65 行 定义 了 commit 方 法 , 该 方法 只 有 在 收 到 了 从 协调 Spout 节 点 发 送 到 消息 提交 流 上 
的 消息 时 才 会 被 调用 。 收 到 该 消息 意味 着 事务 在 系统 中 已 经 被 成 功 处 理 了 ， 此 时 我 们 将 
事务 序号 所 对 应 的 元 数据 从 _cachedMetas 中 有 删除， 并 将 其 值 更 新 至 ZooKeeper 中 。 
通过 分 析 可 以 看 到 ， 每 个 分 区 所 对 应 的 元 数据 只 有 在 事务 成 功 处 理 之 后 才 会 被 存放 在 
ZooKeeper 中 ， 这 与 其 他 类 型 Spout 的 实现 是 不 同 的 。 
ITransactionalSpout 及 IPartitionedTransactionalSpout 都 要 求 每 个 事务 所 对 应 的 数据 要 前 

后 完全 一 致 ， 而 I0paqueTransactionalSpout 并 不 要 求 这 点 ， 其 中 每 个 事务 所 对 应 的 数据 都 是 可 以 

变化 的 ， 但 要 求 事务 之 间 的 数据 没有 重复 。 


15.7 #4 Topology 的 构建 器 


TransactionalTopologyBuilder 用 于 方便 用 户 构建 事务 类 型 的 Topology, 它 将 完成 节点 的 系统 
流 的 添加 及 接收 设置 。 例 如 ， 它 将 为 协调 Spout 节 点 定义 两 个 流 : 事务 流 和 事务 提交 流 。 

TransactionalTopologyBuilder 类 提供 类 似 于 TopologyBuilder 类 的 方法 ， 用 来 设置 Spout 和 
Bolt 节 点 。 它 的 复杂 性 在 于 如 何 将 ITransactionalspout 中 定义 的 协调 Spout 节 点 及 消息 发 送 节 点 部 
署 到 Topology 中 ， 映 射 到 基础 的 Spout 和 Bolt 节 点 上 ， 并 描述 它们 的 依赖 关系 。 

为 了 便于 讨论 ， 本 节 将 该 类 分 成 几 部 分 进行 讨论 。 下 面 首先 分 析 其 构造 函数 以 及 成 员 变 量 。 


15.7.1 构建 器 的 构造 函数 及 成 员 变 量 


TransactionalTopologyBuilder 类 的 定义 如 下 ， 从 其 构造 也 数 可 以 看 出 ， 事 务 Topology 中 只 能 
存在 一 种 类 型 的 Spout 点 。 在 构造 函数 中 , 需要 传人 一 个 ITransactionalSpout 类 型 的 Spout 对 象 。 
详细 分 析 如 下 : 


public class TransactionalTopologyBuilder { 
String id; 
String _spoutId; 
ITransactionalSpout  spout; 
Map«String, Component» bolts = new HashMap«String, Component»(); 
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} 


Integer _spoutParallelism; 
List<Map> _spoutConfs = new ArrayList(); 


// id is used to store the state of this transactionalspout in zookeeper 
// it would be very dangerous to have 2 topologies active with the same id in the same cluster 
public TransactionalTopologyBuilder(String id, String spoutId, ITransactionalSpout spout, Number 
spoutParallelism) { 
_id = id; 
_spoutId = spoutId; 
_spout = spout; 
_spoutParallelism = (spoutParallelism == null) ? null : spoutParallelism.intValue(); 


} 


public TransactionalTopologyBuilder(String id, String spoutId, ITransactionalSpout spout) { 
this(id, spoutId, spout, null); 
} 


public TransactionalTopologyBuilder(String id, String spoutId, IPartitionedTransactionalSpout 
spout, Number spoutParallelism) { 
this(id, spoutId, new PartitionedTransactionalSpoutExecutor(spout), spoutParallelism) ; 


} 


public TransactionalTopologyBuilder(String id, String spoutId, IPartitionedTransactionalSpout 
spout) { 
this(id, spoutId, spout, null); 

} 


public TransactionalTopologyBuilder(String id, String spoutId,IOpaquePartitionedTransactional 
Spout spout, Number spoutParallelism) ( 
this(id, spoutId, new OpaquePartitionedTransactionalSpoutExecutor(spout), spoutParallelism); 


) 


public TransactionalTopologyBuilder(String id, String spoutId,IOpaquePartitionedTransactional 
Spout spout) { 
this(id, spoutId, spout, null); 

} 


public SpoutDeclarer getSpoutDeclarer() { 
return new SpoutDeclarerImp1() ; 
} 


TransactionalTopologyBuildertY) #4 it pk AEN A P3259] A. 


可 以 看 出 ,系统 中 唯一 文 持 的 类 型 为 ITransactionalSpout 类 型 ,其 他 两 种 类 型 为 适 配 的 结果 。 


口 ITransactionalSpout : Spout 实 现 。 它 设置 了 基本 的 类 成 员 变 量 ， 例 如 


TopologyId、SpoutId 和 并 行 度 等 。 


Q IPartitionedTransactionalSpout: 使 用 partitionedTransactionalSpoutExecutor 进 行 封 装 


执行 ， 调 用 参数 为 ITransactionalSpout 类 型 的 构造 函数 。 


口 I0paquePartitionedTransactionalSpout : 使 用 OpaquePartitionedTransactionalSpout 


Executor 进 行 包装 执行 ， 然 后 调用 参数 为 ITransactionalSpout 类 型 的 构造 函数 。 
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下 面 简要 分 析 一 下 该 类 的 成 员 变 量 。 

Q id: 用 来 设置 ToPOLOGY_ TRANSACTIONAL ID, 并 将 其 作为 ZooKeeper 中 元 数据 目录 结构 的 一 部 分 。 
口 _spoutId: Spout 的 名 字 。 由 _spoutld 与 /coordinator 连 接 构成 。 

QO spout: 具体 的 Spout 对 象 ， 类 型 为 ITransactionalSpout。 

口 _bolts: Topology 中 的 Bolt 对 象 。 

Q spoutParallelism: 实际 上 为 消息 发 送 节点 的 数目 ， 其 中 协调 Spout 节 点 只 能 有 一 个 。 

口 _spoutConfs: Spout 对 象 的 配置 项 。 


15.7.2 ”设置 Bolt 对 象 
该 类 中 提供 了 较 多 的 重 载 方法 来 设置 系统 中 的 Bolt 节 点 ， 相 关 代 码 如 下 : 


public BoltDeclarer setBolt(String id, IBatchBolt bolt) { 
return setBolt(id, bolt, null); 
} 


public BoltDeclarer setBolt(String id, IBatchBolt bolt, Number parallelism) { 
return setBolt(id, new BatchBoltExecutor(bolt), parallelism, bolt instanceof ICommitter) ; 
} 


public BoltDeclarer setCommitterBolt(String id, IBatchBolt bolt) { 
return setCommitterBolt(id, bolt, null); 
} 


public BoltDeclarer setCommitterBolt(String id, IBatchBolt bolt, Number parallelism) { 
return setBolt(id, new BatchBoltExecutor(bolt), parallelism, true); 
} 


public BoltDeclarer setBolt(String id, IBasicBolt bolt) { 
return setBolt(id, bolt, null); 
} 


public BoltDeclarer setBolt(String id, IBasicBolt bolt, Number parallelism) { 
return setBolt(id, new BasicBoltExecutor(bolt), parallelism, false); 
} 


private BoltDeclarer setBolt(String id, IRichBolt bolt, Number parallelism, boolean committer) { 
Integer p = null; 
if(parallelism!-null) p = parallelism. intValue(); 
Component component = new Component(bolt, p, committer) ; 
_bolts.put(id, component); 
return new BoltDeclarerImpl(component); 


} 

setBolt 方 法 有 很 多 重 载 ， 它 们 主要 是 为 了 区 分 以 下 几 种 情况 。 

口 IRichBolt: 事务 Topology 的 基本 类 型 。 

口 IBasicBolt: 使 用 BasicBoltExecutor 进 行 封 装 执行 ， 并 调用 第 一 种 类 型 的 构造 函数 。 
口 IBatchBolt: 使 用 BatchBoltExecutor 进 行 封装 执行 ， 并 调用 第 一 种 类 型 的 构造 函数 。 
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事务 提交 Bolt 其 实 为 IBatchBolt 类 型 ， 同 时 实现 了 ICommitter 接 口 的 Bolt 对 象 ，Storm 在 构建 
Topology 的 流 接收 关系 时 会 有 所 不 同 。 例 如 , 在 事务 Topology 中 , 实现 ICommitter 接 口 的 Bolt 将 接 
收 事务 提交 消息 。 另 外 可 以 看 出 ,在 事务 Topology 中 执行 的 Bolt 均 为 IRichBolt 类 型 ， 其 他 类 型 的 
Bolt 节 点 也 会 被 适 配 成 IRichBolt。 另 外 , BatchBoltExecutor 以 及 BasicBoltExecutor 会 对 输入 的 消 
息 进 行 Ack 操 作 ， 若 用 户 想 要 实现 IRichBolt 接 口 ， 则 需要 自己 完成 对 消息 的 Ack 操 作 。 对 消息 进 


行 Ack 操 作 是 Ack 框 架 可 以 正常 工作 的 基础 。 


15.7.3 构建 Topology 
本 节 将 讨论 如 何 来 构建 事务 Topology， 相 关 代码 如 下 : 


public TopologyBuilder buildTopologyBuilder() { 


String coordinator = _spoutId + "/coordinator"; 

TopologyBuilder builder = new TopologyBuilder(); 

SpoutDeclarer declarer = builder.setSpout(coordinator, new TransactionalSpoutCoordinator 
(_spout)) ; 

for(Map conf: _spoutConfs) { 
declarer .addConfigurations(conf) ; 

} 


declarer.addConfiguration(Config. TOPOLOGY TRANSACTIONAL ID, id); 


BoltDeclarer emitterDeclarer - 
builder.setBolt( spoutId, 
new CoordinatedBolt(new TransactionalSpoutBatchExecutor( spout), 
null, 
null), 
_spoutParallelism) 
.allGrouping(coordinator, TransactionalSpoutCoordinator. TRANSACTION BATCH STREAM ID) 
.addConfiguration(Config.TOPOLOGY TRANSACTIONAL ID, id); 
if( spout instanceof ICommitterTransactionalSpout) ( 
emitterDeclarer.allGrouping(coordinator, TransactionalSpoutCoordinator. TRANSACTION_ 
COMMIT STREAM ID); 
} 
for(String id: bolts.keySet()) { 
Component component = bolts.get(id); 
Map«String, SourceArgs> coordinatedArgs = new HashMap«String, SourceArgs>(); 
for(String c: componentBoltSubscriptions(component)) ( 
coordinatedArgs.put(c, SourceArgs.all()); 
} 


IdStreamSpec idSpec = null; 
if(component.committer) { 
idSpec = IdStreamSpec.makeDetectSpec(coordinator, TransactionalSpoutCoordinator. 
TRANSACTION_COMMIT_STREAM_ID); 
} 
BoltDeclarer input = builder.setBolt(id, 
new CoordinatedBolt(component.bolt, 
coordinatedArgs, 
idSpec), 
component.parallelism); 
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37 for(Map conf: component.componentConfs) { 

38 input.addConfigurations(conf); 

39 } 

40 for(String c: componentBoltSubscriptions(component)) { 

41 input.directGrouping(c, Constants.COORDINATED STREAM ID); 

42 } 

43 for(InputDeclaration d: component.declarations) { 

44 d. declare(input); 

45 

46 if(component.committer) { 

47 input.allGrouping(coordinator, TransactionalSpoutCoordinator.TRANSACTION _COMMIT_ 
STREAM ID); 

48 } 

49 

50 return builder; 

51 } 


理解 这 部 分 代码 对 于 理解 事务 Topology 是 非常 重要 的 ， 它 定义 了 各 个 节点 之 间 的 协作 方式 。 

a 第 3 行 创 建 了 一 个 基本 的 TopologyBuilder 对 象 。 

口 第 4 行 设 置 Topology 中 的 协调 Spout 节 点 。 它 利用 TransactionalSpoutCoordinator 对 
ITransationalSpout 中 的 协调 Spout 接 口 进行 封装 执行 。 根 据 之 前 的 分 析 可 以 知道 , Transac 
tionalSpoutCoordinator 实 现 了 IRichspout 接 口 。 

口 第 10~15 行 用 于 设置 Topology 中 的 消息 发 送 节 上 点。 首先， 利用 TransactionalspoutBatch 
Executor 对 ITransactionalSpout 中 的 消息 发 送 接口 进行 封装 ， 然 后 ， 再 利用 Coordinated 
Bolt 进 行进 一 步 的 封装 。 在 事务 Topology 中 执行 的 所 有 Bolt 均 为 CoordinatedBolt 类 型 。 

口 第 16~17 行 设置 消息 发 送 Bolt 通 过 全 局 分 组 的 方式 接收 协调 Spout 中 的 事务 流 。 

O 在 第 18~20 行 中 ， 如 果 Committer 实 现 了 ICommitterTransactionalSpout 接 口 ， 那 么 消息 发 
送 节 点 将 通过 全 局 分 组 的 方式 接收 协调 Spout 中 的 事务 提交 流 。 目 前 ， 这 部 分 是 为 IOpaque 
partitionedTransactionalSpout 设 计 的 。 

a 第 21~49 行 设置 Topology 中 的 Bolt 节 点 ， 这 些 节点 由 用 户 定义 。 

m 第 22~26 行 获得 每 个 Bolt 的 上 游 节 点 组 件 名 称 ， 为 确定 CoordinatedBolt 接 收 哪些 协调 消 

息 流 做 准备 。 

在 第 28~31 行 中 , 若 该 Bolt 实 现 了 ICommiter 接 口 ,将 设置 IdstreamSpec, 含义 为 协调 Spout 

的 消息 提交 流 。 

第 32~36 行 设置 Bolt 对 象 ,它们 均 是 利用 CoordinatedBolt 进 行 封 装 执行 的 。setBolt 函 数 

将 返回 了 一 个 BoltDeclarer 对 象 ， 用 于 完成 由 用 户 定 义 的 流 的 接收 关系 。input 变 量 目 

前 为 类 TopologyBuilder 中 定义 的 BoltGetter 对 象 。 

m 第 40~42 行 用 于 将 Bolt 的 每 一 个 上 游 节 点 均 设置 为 直接 分 组 到 协调 消息 流 上 。 

m 第 43~45 行 是 用 户 自 定义 的 分 组 方式 ， 源 自 于 用 户 逻 辑 。 

m 在 第 46~48 行 中 ， 如 果 Bolt 实 现 了 ICommiter 接 口 ， 则 将 其 设置 为 全 局 分 组 到 协调 Spout 

事务 提交 流 。 


m 
e 


286 % 15% #4 Topology 的 实现 


15.7.4 ”输入 流 声明 器 


在 本 节 讨 论 中 ， 我们 将 各 个 组 件 是 如 何 声 明 其 输入 流 的 。 
内 部 类 Component 主 要 被 事务 Topology 使 用 ， 其 代码 如 下 : 


private static class Component { 
public IRichBolt bolt; 
public Integer parallelism; 
public List<InputDeclaration> declarations = new ArrayList<InputDeclaration>(); 
public List<Map> componentConfs = new ArrayList<Map>(); 
public boolean committer; 


public Component(IRichBolt bolt, Integer parallelism, boolean committer) { 
this.bolt = bolt; 
this.parallelism = parallelism; 
this.committer = committer; 


} 


成 员 变量 declarations 是 List<InputDeclaration> 类 型 的 , 表示 该 组 件 将 接收 哪些 流 , 其 中 接 
口 InputDeclaration 的 定义 如 下 : 


private static interface InputDeclaration { 
void declare(InputDeclarer declarer); 
String getComponent(); 


在 上 述 代码 中 ，declare 方 法 需要 传人 InputDeclarer 对 象 ，InputDeclarer 接 口 在 前 面 章 节 中 
介绍 过 ， 目 前 使 用 类 TopologyBuilder 的 内 部 类 BoltGetter 作 为 其 实现 。 

最 后 , 我 们 看 一 下 BoltDeclarerImp1 的 实现 。 为 节约 篇 幅 , 仅 以 域 分 组 的 实现 为 例 进行 介绍 ， 
其 他 分 组 方式 的 实现 类 似 。 该 类 的 代码 如 下 : 


1 private class BoltDeclarerImpl extends BaseConfigurationDeclarer«BoltDeclarer» implements 
BoltDeclarer { 


2 Component component; 

3 

4 public BoltDeclarerImpl(Component component) { 

5 . component = component; 

6 } 

7 

8 @Override 

9 public BoltDeclarer fieldsGrouping(final String component, final String streamId, 
final Fields fields) { 

10 addDeclaration(new InputDeclaration() { 

11 @Override 

12 public void declare(InputDeclarer declarer) { 

13 declarer. fieldsGrouping(component, streamId, fields); 

14 } 

15 


16 (QOverride 
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17 public String getComponent() ( 
18 return component; 
) 


19 

20 H; 

21 return this; 

22 } 

23 private void addDeclaration(InputDeclaration declaration) { 
24 _component.declarations.add(declaration); 

25 } 

26 


27  QOverride 
28 public BoltDeclarer addConfigurations(Map conf) { 


29 . component . componentConfs . add (conf) ; 
30 return this; 

31 ] 

32] 


口 第 10~19 行 实现 了 接口 InputDeclaration。 第 12~14 行 实现 了 declare 方 法 ， 其 中 调用 了 
declarer 的 fieldsGrouping 方 法 。 目 前 ，declarer 实 际 上 为 BoltGetter 类 型 。 
O 第 23~25 行 定义 了 addDeclaration 方 法 , 它 将 输入 的 declaration 存 人 到 Component 对 象 中 的 
链表 declarations 中 。 
在 这 个 类 的 实现 中 , 我 们 使 用 了 内 部 类 的 概念 以 及 较 多 的 接口 。 内 部 类 技术 使 得 内 部 类 函数 
可 以 直接 访问 外 部 类 的 变量 ,例如 ,传人 的 流 和 分 组 变量 就 必须 被 定义 为 final 类 型 。 


事务 Topology 示 例 


本 章 将 介绍 Storm Starter 中 的 一 个 分 区 事务 Topology 的 例子 ， 读 者 可 以 结合 前 一 章 中 对 事务 
Topology 的 分 析 来 学 习 这 个 例子 。Storm Starter 是 与 Storm 一 起 发 布 的 示例 代码 集合 。 


16.1 例子 代码 


本 节 将 介绍 该 例子 中 各 个 组 件 的 实现 。 它 含有 一 个 分 区 事务 的 Spout 用 于 发 送 数据 ， 同 时 含 
有 局 部 计数 节点 用 于 局 部 计数 ,还 有 全 局 计数 节点 用 于 全 局 的 计数 、 去 重 和 存储 。 该 实例 只 能 在 
LocalCluster 中 运行 ， 不 能 被 部 署 到 集群 环境 中 。 


16.1.1 分 区 的 事务 Spout 

MemoryTransactionalSpout 类 实现 了 IPartitionedTransactionalSpout， 它 利用 三 个 队列 模拟 
的 数据 作为 数据 分 区 。 由 于 该 类 主要 用 于 Storm 的 内 部 测试 , 故 这 里 已 将 与 测试 相关 的 代码 去 除 。 
该 类 的 实现 代码 如 下 : 


1 public class MemoryTransactionalSpout implementsIPartitionedTransactionalSpout 
<MemoryTransactionalSpoutMeta> { 
public static String TX FIELD = MemoryTransactionalSpout.class.getName() + "/id"; 


2 

3 

4 private int takeAmt; 

5 private Fields outFields; 

6 private Map«Integer, List«List«Object»»»  initialPartitions; 
7 
8 


public MemoryTransactionalSpout(Map«Integer, List<List<Object>>> partitions, 
Fields outFields, int takeAmt) { 


9 . id = RegisteredGlobalState.registerState(partitions); 

10 Map«Integer, Boolean» finished - Collections.synchronizedMap(new HashMap«Integer, 
Boolean>()); 

11 _takeAmt = takeAmt; 

12 _outFields = outFields; 

13 _initialPartitions = partitions; 

14 } 

15 

16 @Override 


17 public IPartitionedTransactionalSpout.Coordinator getCoordinator(Map conf, TopologyContext 
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context) { 

18 return new Coordinator(); 

19 } 

20 

21 @Override 

22 public IPartitionedTransactionalSpout.Emitter«MemoryTransactionalSpoutMeta» getEmitter 
(Map conf, TopologyContext context) { 

23 return new Emitter(conf); 

24 } 

25 

26 @Override 

27 public void declareOutputFields(OutputFieldsDeclarer declarer) { 

28 List<String> toDeclare = new ArrayList<String>(_outFields.toList()); 

29 toDeclare.add(0, TX FIELD); 

30 declarer.declare(new Fields(toDeclare)); 

31 } 

32 


33 @Override 
34 public Map<String, Object> getComponentConfiguration() { 


35 Config conf = new Config(); 

36 conf.registerSerialization(MemoryTransactionalSpoutMeta.class); 

37 return conf; 

38 } 

39 

40 public void cleanup() { 

41 RegisteredGlobalState.clearState(_id); 

42 } 

43 

44 private Map<Integer, List<List<Object>>> getQueues() { 

45 Map<Integer, List<List<Object>>> ret = (Map<Integer, List<List<Object>>>) Registered 
GlobalState.getState( id); 

46 if(ret!-null) return ret; 

47 else return initialPartitions; 

48 } 

49 } 


口 _initialpPartitions 为 数据 源 ， 它 的 类 型 为 一 个 哈 希 表 ， 键 为 分 区 号 ， 值 为 一 个 队列 ， 代 
表 分 区 的 数据 。RegisteredGlobalState 类 用 于 存储 全 局 的 数据 ， 它 将 数据 保存 在 一 个 静 
态 的 哈 希 表 中 ， 并 在 访问 数据 时 进行 同步 。 它 的 主要 目标 为 模拟 多 个 Emitter， 并 不 具备 
实际 的 意义 。 第 44~48 行 定义 的 getQueues 方 法 用 于 获得 数据 源 。 该 例子 只 能 通过 
LocalCluster 运 行 ， 而 不 能 放 在 真正 的 集群 中 去 运行 。 

口 _takeAmt 表 示 每 个 事务 所 对 应 的 数据 条 数 。 

口 MemoryTransactionalSpoutMeta 为 事务 所 对 应 的 元 数据 ， 它 在 emitPartitionBatchNew 方 法 
中 产生 。 该 类 需要 由 用 户 实现 ， 相 关 的 定义 如 下 : 


public class MemoryTransactionalSpoutMeta { 
int index; 
int amt; 
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口 第 36 行 进行 序列 化 注册 。 类 MemoryTransactionalSpoutMeta 的 对 象 实例 会 被 写 入 
ZooKeeper 中 。 
O 第 27~31 行 定义 的 declare0utputFields 方 法 需要 将 事务 序号 作为 第 1 列 声明 ， 该 步骤 是 必 
需 的 ， 也 是 初学 者 容易 忘记 的 。 
由 于 MemoryTransactionalSpout 实 现 了 IPartitionedTransactionalSpout 接 口 ， 用 户 需 要 实现 
Coordinator 和 Emitter 接 口 。 

下 面 首先 来 看 Coordinator 接 口 的 实现 ， 其 代码 如 下 : 


class Coordinator implements IPartitionedTransactionalSpout.Coordinator { 


@Override 

public int numPartitions() { 
return getQueues().size(); 

} 


@Override 

public boolean isReady() { 
return true; 

} 


@Override 
public void close() { 


} 
} 


在 上 述 代码 中 ，numPartitions 方 法 会 返回 分 区 的 数目 ，isReady 方 法 则 返回 true。 
接 下 来 看 Emitter 的 接口 实现 : 


1 lass Emitter implements IPartitionedTransactionalSpout.Emitter«MemoryTransactionalSpoutMeta» { 

2 public Emitter(Map conf) { 

3 } 

4 

5 @Override 

6 public MemoryTransactionalSpoutMeta emitPartitionBatchNew(TransactionAttempt tx, 
BatchOutputCollector collector, int partition, MemoryTransactionalSpoutMeta 
lastPartitionMeta) { 

7 int index; 

8 if(lastPartitionMeta==null) { 

9 index = 0; 

10 } else { 

11 index = lastPartitionMeta.index + lastPartitionMeta.amt; 

12 } 

13 List<List<Object>> queue = getQueues().get(partition) ; 

14 int total = queue.size(); 

15 int left = total - index; 

16 int toTake = Math.min(left,  takeAmt); 

17 

18 MemoryTransactionalSpoutMeta ret = new MemoryTransactionalSpoutMeta(index, toTake) ; 


19 emitPartitionBatch(tx, collector, partition, ret); 
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20 return ret; 
21 } 


23 @Override 
24 public void emitPartitionBatch(TransactionAttempt tx, BatchOutputCollector collector, int 
partition, MemoryTransactionalSpoutMeta partitionMeta) ( 


25 List<List<Object>> queue = getQueues().get(partition) ; 

26 for(int i=partitionMeta.index; i < partitionMeta.index + partitionMeta.amt; i++) { 
27 List<Object> toEmit = new ArrayList<Object>(queue.get(i)); 

28 toEmit.add(0, tx); 

29 collector.emit(toEmit); 

30 ) 

31 } 

32 


33 @Override 

34 public void close() { 

35 ] 

36 } 

在 上 述 代 码 中 , 第 6~21 行 定义 了 emitpPartitionBatchNew 方 法 ,该 方法 需要 构建 事务 的 元 数据 ， 
在 处 理 第 一 个 事务 时 ，1astPartitionMeta 为 空 。index 表 示 数 据 队 列 中 的 偏 移 量 ，toTake 表 示 要 
读 取 的 数据 数 上 日 。 对 于 我 们 的 例子 ， 队 列 中 的 数据 读 取 完 成 后 ，toTake 将 为 0， 之 后 的 事务 不 会 
再 有 实际 的 消息 发 送出 去 。 第 18 行 构建 元 数据 ， 第 19 行 调用 emitpartitionBatch 方 法 发 送 数据 ， 
该 方法 会 在 事务 重 传 时 被 调用 。 


16.1.2 局 部 计数 Bolt 的 实现 
首先 来 看 类 Batchcount 的 实现 ， 它 用 于 完成 局 部 计数 ， 其 代码 如 下 : 


1 public static class BatchCount extends BaseBatchBolt { 

2 Object id; 

3 BatchOutputCollector collector; 

4 

5 int count - 0; 

6 

7 @Override 

8 public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, 
Object id) ( 

9 . collector = collector; 

10 _id = id; 

11 } 

12 

13 @Override 

14 public void execute(Tuple tuple) { 

15 _count++}; 

16 } 

17 

18 @Override 


19 public void finishBatch() { 
20 _collector.emit(new Values(_id, _count)); 
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21 } 

22 

23 (QOverride 

24 public void declareOutputFields(OutputFieldsDeclarer declarer) { 
25 declarer.declare(new Fields("id", "count")); 

26 } 

27 } 


该 类 在 execute 方 法 中 对 _count 变 量 进 行 自 增 操作 。 当 属于 一 个 事务 的 消息 结束 时 ， 会 调用 
finishBatch 方 法 将 该 事务 的 局 部 计数 结果 发 送出 去 。 注 意 ，declare0utputFields 方 法 需要 将 事 
务 序号 作为 第 1 列 。 

于 系统 会 为 每 个 事务 都 创建 一 个 新 的 BatchCount 对 象 ， 故 对 于 每 个 事务 ，_count 都 被 初始 


化 为 0。 


16.1.3 全 局 计数 Bolt 的 实现 
下 面 来 看 UpdateGlobalCount 的 实现 ， 它 实现 了 全 局 计数 ， 其 代码 如 下 : 


public static class UpdateGlobalCount extends BaseTransactionalBolt implementsICommitter { 
TransactionAttempt attempt; 
BatchOutputCollector collector; 


@Override 
public void prepare(Map conf, TopologyContext context, BatchOutputCollector collector, 
TransactionAttempt attempt) { 


1 
2 
3 
4 
5 int sum - 0; 
6 
7 
8 


9 . collector = collector; 

10 attempt - attempt; 

11 ) 

12 

13 (QOverride 

14 public void execute(Tuple tuple) { 

15 _sum+=tuple.getInteger (1); 

16 } 

17 

18 @Override 

19 public void finishBatch() { 

20 Value val = DATABASE.get(GLOBAL_COUNT_KEY) ; 
21 Value newval; 

22 if(val == null || !val.txid.equals(_attempt.getTransactionId())) { 
23 newval = new Value(); 

24 newval.txid = _attempt.getTransactionId(); 
25 if(val==null) { 

26 newval.count = _sum; 

27 } else { 

28 newval.count = sum + val.count; 

29 } 

30 DATABASE . put (GLOBAL COUNT KEY, newval); 


31 } else { 
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32 newval = val; 

33 

34 _collector.emit(new Values(_attempt, newval.count)); 
35 } 

36 


37 @Override 

38 public void declareOutputFields(OutputFieldsDeclarer declarer) { 
39 declarer.declare(new Fields("id", "sum")); 

40 } 


a 第 14~16 行 定义 的 execute 方 法 会 从 输入 消息 的 第 1 列 获得 局 部 计数 结果 ， 并 累加 至 _sum 变 

量 中 ,注意 , 每 次 有 新 的 事务 时 都 会 创建 一 个 该 对 象 , 故 _sum 为 一 个 事务 内 部 的 统计 计数 。 

O 第 19~35 行 定义 的 finishBatch 方 法 模拟 了 去 重 操作 。DATABASE 用 于 存储 全 局 计数 结 
Value 对 象 的 键 为 事务 序号 ， 值 为 全 局 计数 。 若 当前 事务 序号 与 Value 中 的 事务 序号 相同 ， 
则 当前 正在 处 理 的 事务 为 事务 重 传 ， 该 事务 对 应 的 结果 已 经 被 更 新 至 DATABASE 对 象 中 了 ， 
此 时 可 以 将 该 事务 重 传 忽略 。 

口 UpdateGlobalCount 类 继承 自 ICommitter ,事务 提交 可 以 保证 强 序 关系 , 故 可 以 在 此 处 去 重 。 
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下 面 我 们 来 看 Topology 的 构建 ， 相 关 代 码 如 下 : 


1 public static final int PARTITION TAKE PER BATCH = 3; 

2 public static final Map«Integer, List<List<Object>>> DATA = new HashMap<Integer, List<List 
«Object»»»() (1 

3 put(0, new ArrayList<List<Object>>() {{ 

4 add(new Values("cat")); 

5 add(new Values("dog")); 

6 add(new Values("chicken")); 

7 add(new Values("cat")); 

8 add(new Values("dog")); 


9 add(new Values("apple")); 

10 Hy 

11 put(1, new ArrayList<List<Object>>() {{ 
12 add(new Values("cat")); 

13 add(new Values("dog")); 

14 add(new Values("apple")); 

15 add(new Values("banana")); 

16 Hy 

17 put(2, new ArrayList<List<Object>>() {{ 
18 add(new Values("cat")); 

19 add(new Values("cat")); 

20 add(new Values("cat")); 

21 add(new Values("cat")); 

22 add(new Values("cat")); 

23 add(new Values("dog")); 


24 add(new Values("dog")); 
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25 add(new Values("dog")); 
26 add(new Values("dog")); 
27 n) 

28 }} 

29 


30 MemoryTransactionalSpout spout = new MemoryTransactionalSpout(DATA, new Fields("word"), PARTITION 
TAKE PER BATCH); 

31 TransactionalTopologyBuilder builder - new TransactionalTopologyBuilder("global-count", "spout", 
spout, 3); 

32 builder.setBolt("partial-count", new BatchCount(), 3) 

33 .noneGrouping("spout"); 

34 builder.setBolt("sum", new UpdateGlobalCount()) 

35 .globalGrouping("partial-count"); 


在 上 述 代码 中 ，PARTITION_TAKE_PER_BATCH 对 应 于 每 个 事务 中 消息 的 数目 ，DATA 用 于 模拟 三 
个 分 区 中 的 数据 。 
O 第 30~31 行 定义 并 设置 Spout 节 点 ， 并 行 度 为 3， 每 个 节点 对 应 于 一 个 分 区 。global-count 
为 ZooKeeper 元 数据 路 径 的 一 部 分 。 
a 第 32~33 行 定义 局 部 计数 节点 ， 并 行 度 为 2。 
口 第 34~35 行 定义 全 局 计数 节点 ， 它 使 用 全 局 分 组 方式 ， 并 行 度 为 1。 


构建 的 Topology 如 图 16-1 所 示 ， 下 面 简要 介绍 一 下 。 


Spout 


spout/coordinator 


coord-stream 


default 
coord-stream defaul 


commit 


partial-count, partial-count, 


coord-stream 
defaul 


coord-stream 


global-count 


图 16-1 


1g 


E% Topology BA 
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O 实 线 为 数据 消息 ， 虚 线 为 控制 消息 。 

口 为 了 简化 该 图 ， 图 中 只 画 了 中 间 的 spouti 节 点 ( Emitter ) 与 partial-count 节 点 之 间 的 流 接收 
关系 ，spouto 和 spoutb 节 点 的 流 接收 关系 与 中 间 的 spouti 节 点 完全 相同 。 

口 spout/coordinator 会 向 batch 流 发 送 事 务 的 初始 化 消息 。 每 个 Spout 节 点 对 应 该 事务 的 一 个 
分 区 。 

口 每 个 spout 节 点 会 向 default 流 发 送 数 据 消 息 ， 向 coord-stream 流 发 送 协调 消息 。 
口 每 个 partial-count 节 点 会 向 global-count 发 送 数据 消息 和 协调 消息 。 


16.3 ”事务 处 理 示 例 
本 节 对 事务 1 和 事务 2 所 发 送 的 消息 进行 列表 分 析 , 理解 这 些 消 息 的 传送 机 制 是 理解 整个 系统 
的 关键 。 
_ OFANA 的 参数 设置 ， 如 表 16-1 所 示 。 例 如 ，partial-counto 节 点 所 对 应 的 表 项 表示 
需要 从 三 个 源 端 Task 接 收 协调 消息 。 
表 16-1 协调 消息 的 参数 设置 
组 ” 件 协调 设置 


spout\coordinator 无 


spouto _sourceArgs: 空 


 idStreamSpec; 空 


[-] 


. numSourceReports ; 


spout, _sourceArgs: 空 


_idStreamSpec: 7: 
_numSourceReports; 0 


spout, _sourceArgs: 空 


_idStreamSpec: 空 
 numSourceReports; 0 

partial-count, _sourceArgs; (spout), spout;, spout;) 
 idStreamSpec. 7: 
 numSourceReports; 3 

partial-count, _sourceArgs; (spout), spout), spout;) 
_idStreamSpec: 空 
 numSourceReports; 3 

global-count _sourceArgs: (partial-counto, partial-count)) 
 idStreamSpec; spout/coordinator 和 的 commit 流 


 numSourceReports; 2 


表 16-2 与 表 16-3 分 别 对 应 于 两 个 事务 的 消息 处 理 情况 ， 其 中 包含 协调 消息 ， 而 具体 的 Ack 消 
息 则 在 此 处 被 忽略 。 
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组 of 


表 16-2 第 一 个 事务 发 送 消息 


示意 


spout\coordinator 


spouto 


spout, 


spout, 


partial-county 


partial-count; 


global-count 


(1, 消息 ID) 表 示 TxID=1 
(1, cat) 分 区 0 对 应 的 数据 


(1, dog) 分 区 0 对 应 的 数据 
(1, chicken) 分 区 0 对 应 的 数据 


(1, partial-counto, 1) 协调 消息 ， 表 示 发 送 


到 jpartial-counto 一 条 消 


(1, partial-counti, 2) 协调 消息 ， T 


(1, cat) 分 区 1 的 数据 
(1, dog) 
(1, apple) 


&m ci 


到 partial-count 一 条 消 


(1, partial-counto, 1) 协调 消息 ， 表 


发 


到 partial-counto 一 条 消 


(1, partial-counti, 2) 协调 消息 ， 


(1, cat) 分 区 2 的 数据 
(1, cat) 分 区 2 的 数 
(1, cat) 分 区 2 的 数据 


&m gm 


送 
送 


zh 
AZ 


A 


到 partial-counto — 4& 1H 


(1, partial-counto, 2) 协调 消息 ， 表 示 发 送 


到 partial-counto 两 条 消 ， 


(1, partial-count,, 1) 协调 消息 9 iie 
到 达 该 节点 


(1, 4) 可 能 有 4 条 消息 到 


&m ci 


到 partial-count 一 条 消 


(1, global-count, 4) 协调 消息 ， 向 global-count 闻 点 发 送 一 条 消息 


(1, 5) 另外 5 条 消息 到 达 该 节点 


(1, global-count, 5) 协调 消息 ， 向 global-count 节 点 发 送 一 条 消息 


(1, 9) 


表 16-3 第 二 个 事务 发 送 消息 


— = 
不 局 
AES 


组 of 发 送 的 消息 示意 
spout\coordinator (2, 消息 ID) 表 示 TxID=2 
spouto (2, dog) 分 区 0 对 应 的 数据 
(2,apple) 分 区 0 对 应 的 数据 
(2, partial-count, 1) 协调 消息 ， 表 示 发 送 到 partial-counto 一 条 消息 
(2, partial-count;, 1) 协调 消息 ， 表 示 发 送 到 partial-counti 一 条 消息 
spout, (2, banana) 分 区 1 的 数据 
(2, partial-counto, 1) 协调 消息 ， 表 示 发 送 到 partial-counto 一 条 消息 
(2, partial-count,, 0) 协调 消息 ， 表 示 发 送 到 partial-count! 零 条 消息 
spout, (2, cat) 分 区 2 的 数据 
(2, cat) 分 区 2 的 数据 
(2, dog) 分 区 2 的 数据 


(2, partial-counto, 2) Hpi 
(2, partial-count,, 1) H} 


HB, ， 表 示 发 送 到 partial-count 两 条 消息 
周 销 息 ， 表 示 发 送 到 partial-count 一 条 消息 
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(E) 
组 ” 件 发 送 的 消息 示意 

partial-counto (1, 2) 可 能 有 两 条 消息 到 达 该 节点 

(1, global-count, 2) 协调 消息 ， 向 global-count 节 点 发 送 一 条 消息 
partial-count, (1,3) 另外 3 条 消息 到 达 该 节点 

(2, global-count, 3) 协调 消息 ， 向 global-count 市 点 发 送 一 条 消息 
global-count (1, 9) 

(2, 5) 


在 事务 Topology 中 ,系统 只 会 跟踪 控制 消息 , 而 不 会 跟踪 数据 消息 。 控制 消息 包括 协调 Spout 
发 送 给 消息 发 送 Bolt 的 事务 消息 ， 以 及 Bolt 之 间 的 协调 消息 等 ， 这 些 消 息 的 根 为 事务 消息 。 

表 16-4 以 Acker Bolt 收 到 的 消息 为 中 心 分 析 事 务 Topology 的 消息 跟踪 过 程 ,为 了 简化 起 见 认为 
每 个 节点 只 发 送 一 条 消息 。 


表 16-4 ”事务 Topology 的 消息 跟踪 


源 组 件 Acker Bolt 收 到 的 消息 示意 
spout\coordinator (TxIdRootld, AckValue, _ack_init) 
spout (TxIdRootld, AckValue, _ack_ack) 
spout, (TxIdRootld, AckValue, _ack_ack) 
spout, (TxIdRootld, AckValue, _ack_ack) 
partial-count (TxIdRootId, AckValue, ack ack) 
partial-count; (TxIdRootld, AckValue, ack ack) 
global-count (TxIdRootld, AckValue, _ack_ack) 


此 时 该 事务 所 对 应 的 跟踪 值 为 零 ，Acker Bolt 将 向 spouticoordinator 发 送 消 息 ， 
表示 该 事务 的 处 理 阶 段 结束 。 
在 事务 提交 阶段 ， 消 息 跟 踪 则 较为 简单 


注意 ，AckValue 是 根据 发 送出 去 的 控制 消息 来 计算 得 到 的 。 在 事务 的 处 理 阶 段 ，Acker Bolt 
一 共 收 到 7 条 消息 ， 分 别 对 应 于 跟踪 的 初始 化 和 跟踪 值 的 更 新 。 


Trident 的 Spout 节 点 


从 本 章 开 始 ， 我 们 将 介绍 Trident 的 实现 。Trident 是 Storm 提 供给 用 户 的 另外 一 套 接口 ， 它 
提供 了 基本 的 流 处 理 功 能 以 及 可 靠 的 消息 处 理 功能 ， 其 中 对 流 的 操作 是 Trident 的 核心 。 读 者 需 
要 首先 阅读 下 面 链接 的 内 容 以 获得 对 Trident 的 宏观 认 知 ,然后 参照 本 书 接 下 来 各 章 的 思路 学 习 
其 实现 。 

O Trident 的 例子 : https://github.com/nathanmarz/storm/wiki/Trident-tutorial。 

口 Trident 的 API 接 口 概述 : https://github.com/nathanmarz/storm/wiki/Trident-API-Overview。 
O Trident 的 Spout 类 型 : https://github.com/nathanmarz/storm/wiki/Trident-spouts。 

口 Trident 的 存储 抽象 : https:/github.commathanmarz/storm/wiki/Trident-state。 

Trident 的 实现 较为 复杂 , 本 书 将 分 成 多 个 章节 对 其 进行 讨论 , 本 章 首 先 介 绍 Trident 中 的 Spout 
节点 类 型 。 

Trident 主 要 支持 两 种 类 型 的 Spout 节 点 : ITridentSpout 以 及 DRPC Spout。 对 于 Storm 中 其 他 基 
本 类 型 的 Spout ， 例 如 IRichspout 和 IBatchSspout ，Trident 进 行 了 接口 适 配 ， 将 它们 适 配 成 为 
ITridentSpout 接 口 并 在 Topology 中 执行 。 主 要 的 类 关系 如 图 17-1 所 示 。 


E IOpaquepartitionedTridentspout | 1 IPartitionedTridentSpout 1 ITridentSpout | E IRichSpout 
rt = -l Ar EA - 
NI A I Xm rum A 
X i \ Ss d Chee tu Jd d dues 
" | à i i i x » | 
€ OpaquePartitionedTridentSpoutExecutor € PartitionedTridentSpoutExecutor| © BatchSpoutExecutor € RichSpoutBatchExecutor € RichSpoutBatchTriggerer 


图 17-1 Trident 中 Spout 节 点 的 类 关系 


本 章 将 详细 分 析 这 些 Spout 节 点 及 适 配 Spout 节 点 的 执行 器 。 


17.1 ITridentSpout 接口 


ITridentSpout 是 Trident 中 唯一 支持 的 Spout 类 型 49 ITransactionalSpout 接口 类 似 ， 
ITridentSpout 接 口 主 要 分 成 两 个 部 分 : 一 部 分 为 协调 Spout 接 口 ， 另 外 一 部 分 为 消息 发 送 Bolt 接 
口 。 不 同 于 事务 Topology 中 的 协调 Spout 节 点 ， 在 Trident 里 协调 Spout 的 逻辑 会 被 部 署 到 多 个 节点 
中 运行 ， 而 消息 发 送 节 点 则 会 被 部 署 到 Bolt 中 执行 。 下 面 首先 介绍 其 协调 Spout 接 口 。 
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17.1.1 BatchCoordinato 接口 


BatchCoordinator 接 口 对 应 于 批 协调 Spout 接 口 (简称 协调 Spout )， 顾 名 思 义 ，Trident 中 的 处 
理 主要 是 基于 批 处 理 的 。 该 接口 的 代码 如 下 : 


1 public interface BatchCoordinator<X> { 

2 /** 

3 * Create metadata for this particular transaction id which has never 

4 * been emitted before. The metadata should contain whatever is necessary 

5 * to be able to replay the exact batch for the transaction at a later point. 
6 * 

7 * The metadata is stored in Zookeeper. 

8 * 

9 * Storm uses the Kryo serializations configured in the component configuration 
10 * for this spout to serialize and deserialize the metadata. 

11 * 

12 * @param txid The id of the transaction. 

13 * (param prevMetadata The metadata of the previous transaction 

14 * (param currMetadata The metadata for this transaction the last time it wasinitialized. 
15 T null if this is the first attempt 

16 * @return the metadata for this new transaction 

17 */ 

18 X initializeTransaction(long txid, X prevMetadata, X currMetadata); 

19 

20 void success(long txid); 

21 

22 boolean isReady(long txid); 

23 

24 /** 

25 * Release any resources from this coordinator. 

26 */ 

27 void close(); 

28 } 


Q initializeTransaction 方 法 返回 通用 类 型 的 变量 X， 它 是 事务 的 元 数据 。X 是 用 户 自 定 义 
的 与 事务 相关 的 数据 类 型 ， 返 回 的 数据 会 被 存储 到 ZooKeeper 中 。 

在 initializeTransaction 方 法 中 ，txid 为 事务 序号 ，prevMetadata 为 前 一 个 事务 所 对 应 的 元 
数据 。 知 当前 事务 为 第 一 个 事务 , 则 prevMetadata 为 空 。currMetadata 是 当前 事务 的 元 数据 ， 
如 果 是 当前 事务 的 第 一 次 尝试 ， 则 为 空 ， 否 则 为 事务 第 一 次 尝试 时 所 产生 的 元 数据 。 

口 isReady 方 法 用 来 判断 事务 所 对 应 的 数据 是 否 已 经 准备 好 了 ， 当 它 返回 true 时 ， 表 示 可 以 
开始 一 个 新 事务 。 在 Trident 中 ，isReady 方 法 传人 了 当前 的 事务 序号 ， 这 是 对 传统 事务 
Topology 的 一 个 改进 。 基 于 传人 的 事务 序号 ， isReady 可 以 获取 相关 的 元 数据 。 

BatchCoordinator 中 实现 的 方法 会 被 部 署 到 多 个 节点 中 和 运行， 其 中 isReady 是 在 真正 的 Spout 

(MasterBatchCoordinator ) 中 执行 的 ， 而 其 他 方法 在 TridentSspoutCoordinator 中 执行 。 理 解 这些 
方法 的 调用 时 机 及 场景 对 于 实现 接口 是 很 有 帮助 的 。 
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17.1.2 TridentSpoutCoordinator 


TridentspoutCoordinator 类 为 BatchCoordinator 的 执行 需 ， 它 继承 自 IBasicBolt 接 口 ， 实 质 
上 为 Bolt 节 点 ,主要 用 于 执行 协调 Spout 接 口中 的 initializeTransaction 方 法 。 可 以 看 出 , 事务 的 
元 数据 是 在 Bolt 节 点 中 产生 的 。 该 类 的 代码 和 分 析 如 下 : 


iini 


public class TridentSpoutCoordinator implements IBasicBolt { 
public static final Logger LOG = LoggerFactory.getLogger(TridentSpoutCoordinator.class); 
private static final String META DIR - "meta"; 


ITridentSpout.BatchCoordinator coord; 
RotatingTransactionalState state; 


1 

2 

3 

4 

5 ITridentSpout _spout; 
6 

7 

8 TransactionalState _underlyingState; 
9 


String id; 
10 
11 public TridentSpoutCoordinator(String id, ITridentSpout spout) { 
12  spout = spout; 
13 “id = id; 
14 } 
15 


16 @Override 
17 public void prepare(Map conf, TopologyContext context) { 


18 _coord = _spout.getCoordinator(_id, conf, context); 

19 _underlyingState = TransactionalState.newCoordinatorState(conf, id); 
20 state = new RotatingTransactionalState( underlyingState, META DIR); 
21 } 

22 


23 GOverride 
24 public void execute(Tuple tuple, BasicOutputCollector collector) { 


25 TransactionAttempt attempt = (TransactionAttempt) tuple.getValue(0); 

26 

27 if(tuple.getSourceStreamId().equals(MasterBatchCoordinator.SUCCESS STREAM ID)) { 

28 _state.cleanupBefore(attempt.getTransactionId()); 

29 _coord.success(attempt.getTransactionId()); 

30 } else { 

31 long txid = attempt.getTransactionId(); 

32 Object prevMeta = state.getPreviousState(txid); 

33 Object meta = coord.initializeTransaction(txid, prevMeta, state.getState(txid)); 
34 _state.overrideState(txid, meta); 

35 collector.emit(MasterBatchCoordinator.BATCH STREAM ID, new Values(attempt, meta)); 
36 ) 

37 

3  ) 

39 


40 @Override 
41 public void cleanup() ( 


42 _coord.close(); 

43 _underlyingState.close(); 
44 } 

45 


46 @Override 


17.1 ITridentSpout 接口 301 


47 public void declareOutputFields(OutputFieldsDeclarer declarer) { 

48 declarer.declareStream(MasterBatchCoordinator.BATCH STREAM ID, new Fields("tx", 
"metadata")); 

49 } 


51 @Override 
52 public Map<String, Object> getComponentConfiguration() { 


53 Config ret = new Config(); 

54 ret.setMaxTaskParallelism(1); 
55 return ret; 

56 } 

57 } 


Q _spout 为 ITridentSpout 的 对 象 引 用 。 这 里 主要 通过 调用 _spout 的 getCoordinator 方 法 来 获 
得 BatchCoordinator 的 引用 ， 然 后 将 该 引用 存储 于 _coord 成 员 变 量 中 。 _state 和 
_underlyingState 用 来 维护 ZooKeeper 中 的 元 数据 。 

O 在 execute 方 法 的 实现 中 ，TridentSpoutCoordinator 将 接收 $success 和 $batch 流 ， 这 两 个 
流 只 包含 一 列 ， 即 事务 序号 txid。 

当 收 到 $success 流 的 消息 时 ， 表 明 事 务 处 理 已 经 结束 ， 于 是 调用 _coord 的 success 方 法 ， 

同时 清理 ZooKeeper 中 的 元 数据 。 

当 收 到 $batch 消 息 时 ，execute 方 法 会 初始 化 一 个 事务 并 将 消息 发 送 到 $batch 流 中 ， 消 

息 的 格式 为 ctx，metadata>。 由 于 收 到 的 消息 可 能 是 重 传 的 消息 ， 例 如 由 Spout 的 超时 

引发 的 重 传 ， 此 时 事务 所 对 应 的 元 数据 可 能 已 经 存在 ， 这 也 是 initializeTransaction 

方法 有 prevMeta 人 参数 的 原因 。 这 与 事务 Topology 是 不 同 的 ， 后 者 对 于 一 个 事务 HK 
initializeTransaction 方 法 只 会 被 调用 一 次 。 

注意 到 Trident 是 在 Bolt 节 点 中 对 事务 进行 初始 化 的 ， 这 与 事务 Topology 也 不 同 ， 后 者 在 

Spout 节 点 中 产生 。Trident 中 的 Spout 节 点 更 类 似 于 一 个 脉冲 服务 器 。 

O 第 52~56 行 规定 了 TridentSpoutCoordinator 的 并 行 度 为 1。 


17.1.3 MasterBatchCoordinator 


MasterBatchCoordinator 类 是 Trident 中 真正 的 Spout 节 点 。Trident 中 可 以 含有 多 个 MasterBatch 
Coordinator 类 型 的 Spout 节 点 ， 每 个 Spout 节 点 又 进一步 对 应 于 一 个 含有 存储 节点 的 节点 组 ( 关于 
节点 组 的 相关 内 容 ， 可 参阅 24.2.1 节 )。 

每 个 MasterBatchCoordinator 节 点 可 以 对 应 多 个 ITridentSpout 节 点 , 这 些 ITridentSpout 节 点 
属于 同一 个 节点 组 。 

MasterBatchCoordinator 类 用 来 产生 一 个 新 的 事务 以 及 判断 一 个 事务 是 否 已 经 被 成 功 处 理 。 
下 面 首先 分 析 其 成 员 变 量 。 该 类 的 定义 如 下 : 


public class MasterBatchCoordinator extends BaseRichSpout { 
public static final Logger LOG -LoggerFactory.getLogger(MasterBatchCoordinator.class); 


public static final long INIT TXID - 1L; 
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口 _spouts 以 及 _managedSspoutIds 用 来 存储 MasterBatchCoordinator 所 管理 


public static final String BATCH STREAM ID = "$batch"; 
public static final String COMMIT STREAM ID - "$commit"; 
public static final String SUCCESS STREAM ID - "$success"; 


private static final String CURRENT TX - "currtx"; 
private static final String CURRENT ATTEMPTS - "currattempts"; 


private List«TransactionalState» states - new Arraylist(); 


TreeMap«Long, TransactionStatus» _activeTx = new TreeMap<Long, TransactionStatus»(); 
TreeMap«Long, Integer» _attemptIds; 


private SpoutOutputCollector collector; 

Long currTransaction; 

int maxTransactionActive; 

List«ITridentSpout.BatchCoordinator» _coordinators = new ArrayList(); 
List«String»  managedSpoutIds; 

List<ITridentSpout>  spouts; 

WindowedTimeThrottler  throttler; 


boolean active - true; 


O INIT_TXID 表 示 最 开始 的 事务 序号 ， 它 从 1 开始 ， 为 长 整 型 。 
O $batch、$commit 和 $success 为 Spout 产 生 的 3 种 流 , 流 中 的 消 ) 


$batch 对 应 于 事务 的 处 理 阶段 (PROCESSING )。 


息 对 应 于 事务 的 某 个 特定 阶段 。 


m $commit 对 应 于 事务 处 理 结束 阶段 (PROCESSED ), 表示 对 事务 中 消息 的 处 理 已 经 完成 ， 


diii 


有 务 等待 被 提交 。 


$success 对 应 于 提交 阶段 (COMMITTING ), 表示 事务 已 经 处 理 结 束 , 通过 向 该 流 发 送 


消息 以 通知 相关 节点 。 相 关节 点 收 到 该 消息 后 ， 可 以 进行 事务 提交 处 理 ， 也 可 以 进行 


历史 事务 数据 的 清理 工作 。 


系统 会 对 发 送 到 $batch 和 $commit 的 消息 进行 跟踪 ， 而 不 会 对 发 送 到 $success 的 消息 进行 


跟踪 。 


口 currtx 以 及 currattempts 对 应 于 ZooKeeper 中 的 元 数据 路 径 ， 分 别 用 来 存储 当前 的 
和 务 尝 试 号 不 再 采用 长 整 型 的 随机 数 , 而 是 采用 递增 的 整数 。 
EAJ Spout o Œ 


事务 所 对 应 的 尝试 ,Trident 中 


hl 


BS All 


Trident 中 ， 同 一 个 节点 组 可 以 包含 多 个 ITridentSpout 类 型 的 Spout 节 点 ， 并 集中 利用 


MasterBatchCoordinator 来 进行 管理 。 


O _states 用 来 存储 每 个 ITridentSspout 所 对 应 的 元 数据 。 

O _activeTx 用 来 保存 每 一 个 事务 的 尝试 状态 。 

口 _attemptIds 用 来 存储 每 一 个 事务 当前 的 尝试 编号 。 

口 _curTrTiransaction 表 示 下 一 个 需要 进行 提交 的 事务 。 

O _maxTiransactionActive 表 示 同 时 运行 的 事务 数目 的 最 大 值 。 
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口 _coordinators 用 来 存储 ITridentSpout 中 的 BatchCoordinator。 
接 下 来 对 该 类 的 主要 函数 进行 分 析 。open 函 数 主要 用 来 对 _states 对 象 进行 初始 化 ， 该 函数 会 
根据 ZooKeeper 所 保存 的 内 容 进行 数据 恢复 , 以 便于 系统 从 上 次 结束 的 地 方 继续 运行 ,其 代码 如 下 : 


1 public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) { 
2 _throttler = newWindowedTimeThrottler((Number)conf.get(Config.TOPOLOGY TRIDENT BATCH. 
EMIT INTERVAL MILLIS), 1); 


3 for(String spoutId: _managedSpoutIds) { 

4 _states.add(TransactionalState.newCoordinatorState(conf, spoutId)); 

5 } 

6 _currTransaction = getStoredCurrTransaction(); 

7 

8 _collector = collector; 

9 Number active = (Number) conf.get(Config. TOPOLOGY MAX SPOUT PENDING) ; 

10 if(active--null) { 

11 _maxTransactionActive = 1; 

12 } else { 

13 _maxTransactionActive = active.intValue(); 

14 } 

15 _attemptIds = getStoredCurrAttempts(_currTransaction, _maxTransactionActive) ; 
16 

17 

18 for(int i-0; i« spouts.size(); i++) { 

19 String txId = _managedSpoutIds.get (i); 

20 _coordinators.add(_spouts.get(i).getCoordinator(txId, conf, context)); 
21 } 

22 } 


it, 


口 第 6 行 获取 正在 运行 的 事务 序号 。 这 里 会 以 所 有 Spout 中 存储 的 最 大 的 事务 序号 作为 


_currTransaction 的 值 。 
目前 这 个 类 中 管理 的 每 一 个 Spout 节 点 都 需要 独立 地 维护 其 当前 事务 及 每 个 事务 的 当前 
尝试 序号 。 不 过 在 目前 的 实现 中 ， 每 个 Spout 的 这 些 数据 都 是 一 致 的 ， 这 增加 了 额外 的 同 
步 负担 ， 我 认为 这 是 需要 改进 的 地 方 。 
口 第 15 行 获取 每 个 事务 所 对 应 的 当前 尝试 值 。 与 前 面 类 似 ， 这 里 也 会 取 所 有 Spout 中 存储 的 
关于 _currTransaction 事 务 序号 中 的 最 大 值 。 
a 第 18~21 行 初始 化 _coordinators， 即 该 Spout 代 理 的 ITridentSpout 节 点 。 
declare0utputFields 方 法 定义 输出 的 三 个 流 , 它们 的 模式 均 为 只 包含 要 处 理 的 事务 序号 。 理 
解 这 些 流 是 如 何 被 接收 的 ， 对 于 理解 整个 系统 来 说 十 分 重要 。 该 方法 的 代码 如 下 : 


public void declareOutputFields(OutputFieldsDeclarer declarer) { 
// in partitioned example, in case an emitter task receives a later transaction 
than it's emitted so far, 
// when it sees the earlier txid it should know to emit nothing 
declarer.declareStream(BATCH STREAM ID, new Fields("tx")); 
declarer.declareStream(COMMIT STREAM ID, new Fields("tx")); 
declarer.declareStream(SUCCESS STREAM ID, new Fields("tx")); 
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Sync 方法 主要 用 于 产生 新 的 事务 ， 其 代码 如 下 : 


1 private void sync() { 
2 // note that sometimes the tuples active may be less than max spout pending, e.g. 
3 // max spout pending - 
4 // tx 1, 2, 3 active, tx 2 is acked. there won't be a commit for tx 2 (because 
tx 1 isn't committed yet), 
5 // and there won't be a batch for tx 4 because there's max spout pending tx active 
6 TransactionStatus maybeCommit = _activeTx.get(_currTransaction) ; 
7 if(maybeCommit!-null 8& maybeCommit.status == AttemptStatus.PROCESSED) { 
8 maybeCommit.status = AttemptStatus. COMMITTING; 
9 _collector.emit (COMMIT STREAM ID, new Values(maybeCommit.attempt), maybeCommit.attempt) ; 


10 } 

11 

12  if( active) { 

13 if( activeTx.size() « maxTransactionActive) { 

14 Long curr - currTransaction; 

15 for(int i-0; i« maxTransactionActive; i++) { 

16 if(! activeTx.containsKey(curr) && isReady(curr)) { 

17 // by using a monotonically increasing attempt id, downstream tasks 
18 // can be memory efficient by clearing out state for old attempts 
19 // as soon as they see a higher attempt id for a transaction 

20 Integer attemptId = attemptIds.get(curr); 

21 if(attemptId--null) { 

22 attemptId - 0; 

23 ) else { 

24 attemptId++; 

25 } 

26 _attemptIds.put(curr, attemptId); 

27 for(TransactionalState state: states) { 

28 state.setData(CURRENT ATTEMPTS, _attemptIds) ; 

29 } 

30 

31 TransactionAttempt attempt = new TransactionAttempt(curr, attemptId); 
32 _activeTx.put(curr, new TransactionStatus(attempt)); 

33 _collector.emit(BATCH STREAM ID, new Values(attempt), attempt); 
34  throttler.markEvent(); 

35 

36 curr - nextTransactionId(curr); 

37 } 

38 } 

39  } 

40 } 


a 第 7~10 行 判断 当前 事务 currTransaction 的 状态 是 否 为 处 理 成 功 阶段 ， 若 已 被 成 功 处 理 ， 
则 向 $commit 流 发 送 消息 ， 收 听 该 流 的 节点 会 根据 这 个 消息 来 调用 finishBatch 方 法 ， 从 而 
完成 对 事务 的 提交 和 后 处 理 。 

O 第 12~38 行 用 来 判断 是 否 产生 一 个 新 的 事务 。 系 统 中 最 多 允许 _maxTransactionActive 个 事务 
同时 运行 ， 当 前 活跃 的 事务 的 序号 区 间 为 [_currTxId, _currTxId+_maxTransaction 
Active-1]。 注 意 ， 只 有 在 当前 事务 结束 之 后 ， 系 统 才 会 初始 化 新 的 事务 ， 所 以 系统 中 实 
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际 活 跃 的 事务 可 能 少 于 _maxTransactionActive 中 定义 的 数 上 日 。 

口 第 16 行 根据 isReady 方 法 来 判断 是 否 可 以 初始 化 一 个 新 事务 。 目 前 ， 只 要 任何 一 个 
BatchCoordinator 的 isReady 方 法 返回 true， 系 统 就 会 开始 一 个 新 事务 。 这 部 分 是 需要 改进 
的 。 例 如 ， 两 个 流 要 进行 连接 时 ， 需 要 保证 在 对 应 的 两 个 Spout 中 ， 消 息 发 送 节 点 所 发 送 
的 数据 处 于 同一 个 事务 序号 下 ， 这 样 才能 连接 ， 这 也 要 求 isReady 方 法 应 该 同时 返回 true。 
下 面 的 代码 为 目前 isReady 的 实现 : 


private boolean isReady(long txid) ( 
if( throttler.isThrottled()) return false; 
//TODO: make this strategy configurable?... right now it goes if anyone is ready 
for(ITridentSpout.BatchCoordinator coord: coordinators) { 
if(coord.isReady(txid)) return true; 


return false; 


} 


O 第 33 行 向 $batch 流 发 送 新 初始 化 的 事务 消息 。 注 意 , 所 有 发 送出 去 的 消息 都 会 被 跟踪 。 其 
他 节点 则 通过 全 局 分 组 的 方式 进行 收听 。 
当 发 送 至 $batch 以 及 $commit 的 消息 被 Ack 后 ， 下 面 的 方法 就 会 被 调用 : 


1 public void ack(Object msgId) { 

2 TransactionAttempt tx = (TransactionAttempt) msgId; 

3 TransactionStatus status = activeTx.get(tx.getTransactionId()); 
4 if(status!-null 8& tx.equals(status.attempt)) { 

5 if(status.status--AttemptStatus.PROCESSING) { 

6 status.status - AttemptStatus.PROCESSED; 

7 } else if(status.status--AttemptStatus.COMMITTING) { 

8 _activeTx. remove(tx.getTransactionId()); 


9 _attemptIds.remove(tx.getTransactionId()); 

10 _collector.emit(SUCCESS STREAM ID, new Values(tx)); 

11 _currTransaction = nextTransactionId(tx.getTransactionId()); 
12 for(TransactionalState state: states) { 

13 state.setData(CURRENT TX, currTransaction); 

14 

15 

16 sync(); 

17 

18 } 


a 第 5~7 行 收 到 发 送 至 $batch 流 的 Ack 消 息 ， 表 明 事 务 的 数据 处 理 已 经 结束 ( 事务 中 的 数据 

在 Bolt 方 点 上 均 已 调用 execute 方 法 )， 此 时 将 事务 的 状态 改 为 PROCESSED。 

O 第 8~14 行 收 到 发 送 至 $commit 的 Ack 消 息 ， 表 示 该 事务 提交 已 经 被 成 功 处 理 。 此 时 会 向 
$success 流 发 送 消息 , 相关 节点 根据 该 消息 进行 清理 及 后 处 理 等 操作 。 第 11 行 将 当前 事务 
序号 更 新 为 下 一 个 事务 序号 。 第 12~14 行 将 每 一 个 Spout 所 对 应 的 当前 事务 信息 更 新 到 
ZooKeeper 中 。 

在 收 到 失败 消息 时 , 失败 的 事务 及 其 后 续 事 务 都 需要 重 传 ,但 事务 的 元 数据 并 不 会 重新 产生 ， 
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而 是 利用 之 前 初始 化 的 内 容 获得 。fail 方 法 的 实现 代码 如 下 : 


1 public void fail(Object msgId) { 

2 TransactionAttempt tx = (TransactionAttempt) msgId; 

3 TransactionStatus stored = activeTx.remove(tx.getTransactionId()); 
4 if(stored!=null 8& tx.equals(stored.attempt)) { 

5 _activeTx.tailMap(tx.getTransactionId()).clear(); 

6 sync; 

7 

8 


} 


17.1.4 消息 发 送 节 点 接口 


ITridentSpout 的 消息 发 送 节 点 接口 逻辑 会 被 部 署 到 Bolt 节 点 中 和 运行。 消息 发 送 节 点 会 收听 协 
调 Spout 的 $batch 和 $success 流 。 当 收 到 源 自 $batch 流 中 的 消息 时 , 节点 便 调 用 emitBatch 方 法 来 发 
送 数 据 。 消 息 发 送 节 点 的 接口 定义 如 下 : 


public interface Emitter«X» { 
/** 


* Emit a batch for the specified transaction attempt and metadata for the transaction. The metadata 
* was created by the Coordinator in the initializeTranaction method. This method must always emit 


* the same batch of tuples across all tasks for the same transaction id. 
* 


*/ 
void emitBatch(TransactionAttempt tx, X coordinatorMeta, TridentCollector collector); 
/** 

* This attempt committed successfully, so all state for this commit and before 

can be safely cleaned up. 

*/ 
void success(TransactionAttempt tx); 

/** 

* Release any resources held by this emitter. 

*/ 
void close(); 


) 


口 x 类 型 的 coordinatorMeta 由 BatchCoordinator 中 的 initializeTransaction 方 法 初始 化 得 到 。 
O 参数 collector 用 来 向 外 发 送 数 据 。 由 于 Trident 可 能 将 多 个 操作 放 在 一 个 Bolt 中 执行 , 此 处 
Hicollector 可 能 只 是 调用 同一 个 Bolt 中 的 其 他 操作 来 处 理 其 输出 ， 而 并 不 是 真正 向 外 发 
送 数据 ， 详 情 可 参见 第 24 章 。 
O 当 收 到 $success 流 的 消息 时 ， 会 调用 success 方 法 对 事务 进行 后 处 理 等 。 


17.1.5 ”消息 发 送 接口 的 执行 器 


ITridentSpout 中 的 消息 发 送 接 口 逻辑 是 在 TridentSpoutExecutor 中 执行 的 ， 该 类 实现 了 
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ITridentBatchBolt 接 口 。TridentSpoutExecutor 会 在 其 execute 方 法 中 根据 收 到 消息 的 流 号 来 调用 
消息 发 送 接口 中 的 相应 方法 。 这 里 主要 分 析 其 execute 方 法 的 实现 : 


1 public void execute(BatchInfo info, Tuple input) { 

2 // there won't be a BatchInfo for the success stream 

3 TransactionAttempt attempt = (TransactionAttempt) input.getValue(0); 

4 if(input.getSourceStreamId().equals(MasterBatchCoordinator.COMMIT STREAM ID)) { 
5 if(attempt.equals( activeBatches.get(attempt.getTransactionId()))) { 

6 ((ICommitterTridentSpout.Emitter)  emitter).commit(attempt); 

7  activeBatches.remove(attempt.getTransactionId()); 
8 } else { 


9 throw new FailedException("Received commit for different transactionattempt"); 
10 

11 } else if(input.getSourceStreamId().equals(MasterBatchCoordinator.SUCCESS STREAM ID)) { 
12 // valid to delete before what's been committed since 

13 // those batches will never be accessed again 

14 _activeBatches.headMap(attempt.getTransactionId()).clear(); 

15 _emitter.success(attempt) ; 

16 } else { 

17 . collector.setBatch(info.batchId); 

18  emitter.emitBatch(attempt, input.getValue(1), collector); 

19 _activeBatches.put(attempt.getTransactionId(), attempt); 

20 } 

21 } 


口 通常 ，BatchInfo 对 象 中 含有 与 输入 消息 input 的 第 1 列 相同 的 元 素 。 不 过 对 于 $success 流 ， 
传人 的 BatchInfo 对 象 为 空 , 相关 内 容 会 在 第 26 章 中 进一步 讨论 。 第 3 行 统一 地 从 输入 消息 
地 第 1 列 获得 事务 信息 。 

口 在 第 4~10 行 中 ， 只 有 在 实现 了 ICommitterTridentSpout 接 口 后 ，Topology 构 建 器 才 会 去 收 
听 $commit 流 。 收 到 从 这 个 流 发 来 的 消息 时 execute 方 法 将 调用 消息 发 送 接口 Emitter 的 
commit 方 法 。 

O 第 12~15 行 处 理 来 自 $success 流 的 消息 ， 这 里 调用 _emitter 的 success 方 法 。 

O 第 16~21 行 处 理 来 自 $batch 流 的 消息 ， 这 里 调用 _emitter 的 emitBatch 方 法 发 送 消 息 ， 其 中 

_collector 为 AdIdCollector 类 型 。 AdIdCollector 在 发 送 消 息 时 , 会 将 事务 序号 添加 到 第 1 列 。 

口 _activeBatches 用 来 存储 当前 节点 上 运行 的 事务 以 及 尝试 编号 ， 以 便 在 实现 了 
ICommitterTridentSpout 的 节点 上 保证 提交 的 事务 编号 与 $commit 流 消息 中 的 事务 序号 相 
同 。 它 主 要 用 于 模 精 事 务 类 型 ， 即 同一 个 事务 的 不 同 尝试 都 可 能 对 应 着 不 同 的 数据 ， 事 
务 提交 时 必须 保证 使 用 了 正确 的 事务 以 及 尝试 编号 ， 仪 仅 事 务 编号 相同 是 不 够 的 。 

a 第 14 行 清除 掉 当 前 事务 编号 之 前 的 事务 数据 ， 而 第 7 行 则 清除 掉 了 当前 的 事务 。 


17.2” 适 配 IRichSpout 接口 


为 了 更 好 地 与 其 他 接口 相 兼 容 ，Trident 对 基础 的 Spout 接 口 进行 了 适 配 。 
在 Trident 中 ，IRichSspout 并 不 是 放 在 Spout 节 点 中 运行 , 而 是 在 Bolt 节 点 中 。 上 默认 的 Spout 节 点 
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会 处 理 消 息 超时 ， 以 及 对 Ack、Fail 方 法 的 回调 等 ， 然 而 通常 的 Bolt 节 点 并 不 具备 这 些 功能 。 
RichSpoutBatchExecutor 类 对 这 些 行为 进行 了 适 配 模 拟 ，IRichspout 接口 被 适 配 成 为 
ITridentSpout 接 口 。 
Spout 节 点 通过 ISpout0utputCollector 类 来 发 送 消息 ， 这 与 Bolt 节 点 中 使 用 0utputCollector 
是 不 一 致 的 ， 因 此 需要 类 captureCollector 对 其 进行 适 配 。 下 面 首先 分 析 CaptureCollector,， 其 
代码 如 下 : 


static class CaptureCollector implements ISpoutOutputCollector { 


TridentCollector collector; 
public List«Object» ids; 
public int numEmitted; 


public void reset(TridentCollector c) { 
. collector = c; 
ids = new ArrayList<Object>(); 


) 


(QOverride 

public void reportError(Throwable t) { 
. collector.reportError(t); 

} 


(QOverride 
public List«Integer» emit(String stream, List«Object» values, Object id) ( 
if(id!=null) ids.add(id); 
numEmitted++; 
_collector.emit(values) ; 
return null; 


} 


(QOverride 

public void emitDirect(int task, String stream, List«Object» values, Object id) { 
throw new UnsupportedOperationException("Trident does not support direct streams"); 

} 


} 


口 _collector 为 TridentCollector 类 型 ， 其 实际 类 型 为 Bolt 的 0utputCollector。 

口 _ids 成 员 变 量 负 责 记 录用 于 消息 跟踪 的 消息 号 Messageld。 

O numEmitted 用 来 记录 发 送出 去 的 消息 条 数 , 以 此 实现 流量 控制 。 Spout 通 过 maxSpoutPending 
来 完成 控制 ， 当 发 送 消 息 的 数目 过 多 时 ，Spout 节 点 将 处 于 不 活跃 状态 。 

接 下 来 分 析 消 息 发 送 接口 的 实现 ， 相 关 代 码 如 下 : 


1 class RichSpoutEmitter implements ITridentSpout.Emitter«Object» { 
2 int maxBatchSize; 

3 boolean prepared - false; 

4 CaptureCollector collector; 

5 RotatingMap«Long, List«Object»» idsMap; 
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Map conf; 

TopologyContext context; 

long lastRotate - System.currentTimeMillis(); 
long rotateTime; 


public RichSpoutEmitter(Map conf, TopologyContext context) { 
conf = conf; 
context - context; 
Number batchSize - (Number) conf.get(MAX BATCH SIZE CONF); 
if(batchSize--null) batchSize - 1000; 
 maxBatchSize - batchSize.intValue(); 
collector - new CaptureCollector(); 
idsMap - new RotatingMap(3); 
rotateTime - 1000L * ((Number)conf.get(Config.TOPOLOGY MESSAGE TIMEOUT SECS)) 
.intValue(); 


@Override 


public void emitBatch(TransactionAttempt tx, Object coordinatorMeta, TridentCollector 
collector) { 
long txid = tx.getTransactionId(); 


long now = System.currentTimeMillis(); 
if(now - lastRotate > rotateTime) { 
Map<Long, List<Object>> failed = idsMap.rotate(); 
for(Long id: failed.keySet()) { 
//TODO: this isn't right... it's not in the map anymore 
fail(id); 
} 
lastRotate = now; 


} 


if(idsMap.containsKey(txid)) { 
fail(txid); 
} 


. collector.reset(collector); 
if(!prepared) ( 
 Spout.open( conf, context, new SpoutOutputCollector( collector)); 
prepared - true; 
} 
for(int i-0; i« maxBatchSize; i++) { 
_spout.nextTuple(); 
if( collector.numEmitted « i) ( 
break; 
} 


} 
idsMap.put(txid, _collector.ids); 


} 


@Override 
public void success(TransactionAttempt tx) { 
ack(tx.getTransactionId()); 
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58 } 

59 

60 private void ack(long batchId) { 

61 List<Object> ids = (List<Object>) idsMap.remove(batchId); 
62 if(ids!-null) { 

63 for(Object id: ids) { 

64 _spout.ack(id); 

65 } 

66 } 

67 } 

68 

69 private void fail(long batchId) { 

70 List<Object> ids = (List<Object>) idsMap.remove(batchId) ; 
71 if(ids!-null) { 

72 for(Object id: ids) { 

23 _spout.fail(id); 

74 } 

75 } 

76 

77 } 


口 _maxBatchSize 的 作用 类 似 于 maxSpoutpPending 变 量 ， 它 根据 MAX_BATCH SIZE_CONF 来 设置 。 
口 rotateTime 由 TOPOLOGY_ MESSAGE TIMEOUT_SECS 设 置 ， 用 来 控制 消息 超时 。 
口 idsMap 用 来 保存 Spout 在 发 送 消息 时 所 附带 的 消息 序号 Messageld。 键 为 事务 序号 ， 值 为 属 
于 该 事务 的 所 有 消息 的 消息 号 。 
口 第 23~53 行 实现 了 emitBatch 方 法 。 
m 第 27~34 行 根据 超时 时 间 设 置 来 判断 是 否 该 对 消息 进行 失败 处 理 ， 这 里 将 调用 Spout 的 
fail 方 法 。 
第 36~38 行 对 当前 事务 所 属 的 消息 调用 fail 方 法 ， 主 要 来 应 对 事务 重 传 的 情况 。 
第 40 行 对 _collector 调 用 reset 方 法 ， 清 空 已 缓存 的 消息 序号 Messageld。 
第 41~44 行 调用 Spout 的 open 方 法 ， 并 设置 prepared 变 量 来 防止 多 次 调用 。 
第 45~50 行 不 断 调用 Spout 的 nextTuple 方 法 来 产生 消息 。 注 意 第 42 行 传人 了 利用 
CaptureCollector 初 始 化 的 SpoutoutputCollector 。 所 以 Spout 实 际 上 是 通过 Bolt 的 
0utputCollector 发 送 消息 的 ， 并 且 对 消息 号 Messageld 进 行 了 记录 。 当 一 次 nextTuple 疝 
数 调 用 未 向 外 发 送 任何 消息 时 ， 称 为 一 次 空 跑 。 此 处 对 空 跑 的 控制 是 有 问题 的 ， 由 于 
_collector 的 numEmitted 变 量 并 没有 被 重 置 ， 这 将 导致 接 下 来 的 事务 对 空 跑 的 控制 是 失 
效 的 。 故 需要 在 CaptureCollector 的 Yeset 方 法 中 将 numEmitted 设 置 为 0。 
O 在 第 56~58 行 中 ， 收 到 $success 流 的 消息 时 ， 表 明 一 个 事务 的 处 理 已 经 完成 ， 于 是 调用 
_spout 的 Ack 方 法 。 这 里 我 们 看 到 了 $success 是 如 何 被 利用 的 。 
ITridentSpout 的 Coordinator 接 口 实现 起 来 很 简单 ， 它 只 是 在 isReady 方 法 中 返回 true。 
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17.3” 适 配 IBatchSpout 接口 


IBatchSpout 和 ITridentSpout 中 的 消息 发 送 接 口 较为 接近 ， 都 是 进行 批 处 理 的 。 在 Trident 中 ， 
我 们 利用 BatchspoutExecutor 来 执行 IBatchspout 。 类 似 地 , BatchSpoutExecutor 也 实现 了 
ITridentSpout 接 口 ， 下 面 来 看 其 接口 实现 : 


public class BatchSpoutEmitter implements Emitter { 


@Override 

public void emitBatch(TransactionAttempt tx, Object coordinatorMeta, TridentCollector collector) { 
 spout.emitBatch(tx.getTransactionId(), collector); 

) 


@Override 

public void success(TransactionAttempt tx) { 
_spout.ack(tx.getTransactionId()); 

} 


@Override 
public void close() { 
_spout.close(); 
} 
} 
O 在 emitBatch 方 法 中 , 我 们 调用 了 _spout 的 emitBatch 方 法 。IBatchBolt 不 需要 元 数据 支持 。 
在 success 方 法 中 ， 我 们 调用 了 _spout 的 ack 方 法 ， 表 示 一 个 事务 已 经 处 理 结 
口 Coordinator 的 实现 只 是 在 isReady 方 法 中 返回 true， 同 样 地 ， 事 务 相 关 的 元 数据 为 空 。 
口 IBatchspout 的 emitBatch 方 法 需要 传人 事务 序号 。 实 现 IBatchSpout 的 用 户 类 可 以 利用 事务 
序号 与 元 数据 进行 关联 。 


17.4 Trident 中 分 区 的 Spout 类 型 
Trident 提 供 了 类 似 于 分 区 事务 Topology 的 接口 类 型 ， 采 用 的 实现 技术 也 是 相似 的 ， 即 首先 定 


义 用 户 接 口 ， 然 后 定义 一 个 执行 类 ， 并 将 该 接口 适 配 成 为 ITridentSpout 接 口 。 本 节 将 对 Trident 
中 的 分 区 Spout 类 型 进行 分 析 。 


17.4.1 分 区 Spout 接 口 


IPartitionedTridentSpout 接 口 用 于 人 处理 输入 数据 已 经 被 分 区 的 情况 。 例 如 在 Kafka 队 列 中 ， 
数据 以 分 区 的 形式 存放 在 不 同 的 机 器 (Broker) 上 ， 此 时 便 可 实现 这 个 接口 来 完成 对 Kafka 的 数 
据 读 取 ， 每 个 事务 都 会 分 别 从 一 个 分 区 上 读 取 一 定 的 数据 。 
事务 的 元 数据 存储 于 ZooKeeper 中 。 当 事务 处 理 失败 后 ,会 利用 该 元 数据 重新 读 取 Kafka 队 列 ， 
这 样 可 以 保证 事务 重 传 时 处 理 的 是 相同 的 数据 。 
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IPartitionedTridentSpout 接 口 与 TPartitionedTransactionalSpout 接 口 是 很 类 似 的 ， 读 者 可 
以 对 比 这 两 个 接口 的 异同 来 学 习 。IPartitionedTransactionalSpout 的 代码 如 下 : 


/** 
* This interface defines a transactional spout that reads its tuples from a partitioned set of 
* brokers. It automates the storing of metadata for each partition to ensure that the same batch 
* is always emitted for the same transaction id. The partition metadata is stored in Zookeeper. 
*/ 
public interface IPartitionedTridentSpout«Partitions, Partition extends ISpoutPartition, T» extends 
Serializable { 
public interface Coordinator<Partitions> { 
/** 
* Return the partitions currently in the source of data. The idea is 
* is that if a new partition is added and a prior transaction is replayed, it doesn't 
* emit tuples for the new partition because it knows what partitions were in 
* that transaction. 
*/ 
Partitions getPartitionsForBatch(); 


boolean isReady(long txid); 


void close(); 


) 


public interface Emitter«Partitions, Partition extends ISpoutPartition, X» ( 


List«Partition» getOrderedPartitions(Partitions allPartitionInfo); 


/** 
* Emit a batch of tuples for a partition/transaction that's never been emitted before. 
* Return the metadata that can be used to reconstruct this partition/batch in the future. 
id 
X emitPartitionBatchNew(TransactionAttempt tx, TridentCollector collector, Partition 
partition, X lastPartitionMeta); 


/** 

* This method is called when this task is responsible for a new set of partitions. Should be 
used 

* to manage things like connections to brokers. 


zy 
void refreshPartitions(List«Partition» partitionResponsibilities); 


/** 

* Emit a batch of tuples for a partition/transaction that has been emitted before, using 

* the metadata created when it was first emitted. 

*/ 

void emitPartitionBatch(TransactionAttempt tx, TridentCollector collector, Partition 
partition, X partitionMeta); 

void close(); 


} 


Coordinator<Partitions> getCoordinator(Map conf, TopologyContext context) ; 
Emitter<Partitions, Partition, T> getEmitter(Map conf, TopologyContext context) ; 
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Map getComponentConfiguration(); 
Fields getOutputFields(); 


j 

口 IPartitionedTridentSpout 中 有 3 个 通用 类 型 . Partitions, PartitionfllX, Coordinator'} 
存储 数据 的 类 型 为 Partitions， 为 通用 类 型 ， 其 含义 为 分 区 的 元 数据 。 例 如 ,一 共存 在 多 
少 个 分 区 , 分 区 所 在 的 Broker， 等 等 都 属于 这 种 类 型 。 具 体 信息 由 用 户 定 义 ， 不 过 这 部 分 
数据 是 需要 保持 相对 稳定 的 。 

口 在 IPartitionedTrident 接口 中 ， 通 过 调用 getorderedpPartitions 方 法 根据 输入 的 
Partitions 类 型 获得 Partition 的 列表 。 同 样 地 ，Partition 也 为 通用 类 型 ， 但 是 它 要 继承 
自 ISpoutPartition 接 口 ， 即 含有 getId 方 法 来 获得 Partition 的 编号 ID。 

口 类 型 x 表示 人 处理 某 个 Partition 在 某 一 个 事务 上 面 对 应 的 元 数据 类 型 。 例如 , 这 个 事务 要 读 

取 的 Partition 数 据 的 区 间 。 

口 Coordinator 的 isReady 方 法 用 来 判断 输入 的 事务 是 否 可 以 开始 ， 例 如 ， 可 以 判断 Kafka 队 

列 中 是 否 存 在 新 数据 。 

口 Emitter 的 getOrderedPartitions 方 法 会 在 分 区 元 数据 发 生变 化 ( 即 Partitions 发 生变 化 ) 
时 被 调用 。 该 方法 与 refreshPartitions 的 调用 时 机 相同 ， 用 来 应 对 分 区 的 变化 。 例 如 ， 
建立 并 维护 与 新 增加 Partition 的 连接 就 可 以 使 用 这 个 方法 。 

口 emitpPartitionBatchNew 方 法 会 在 事务 第 一 次 尝试 时 被 调用 ， 其 参数 lastPartitionMeta 表 
示 该 分 区 的 上 一 次 事务 所 对 应 的 元 数据 。 该 方法 将 返回 当前 事务 在 当前 分 区 的 元 数据 ， 
该 数据 会 被 存储 在 ZooKeeper 中 。 

D emitpPartitionBatch 方 法 会 在 事务 被 重 试 时 调用 ， 其 元 数据 是 在 emitPartitionBatchNew 方 
法 中 创建 的 。 该 方法 不 会 更 新 元 数据 ， 于 是 保证 了 事务 是 处 理 相同 的 数据 的 。 


17.4.2 ”分 区 Spout 的 执行 器 


PartitionedTridentSpoutExecutor 类 实现 了 ITridentSpout 接口 ， 它 对 IPartitioned 
TridentSpout 进 行 了 适 配 ， 使 其 能 够 被 Trident 执 行 。 该 类 的 代码 如 下 : 


public class PartitionedTridentSpoutExecutor implements ITridentSpout«Integer» ( 
IPartitionedTridentSpout  spout; 


1 

2 

3 

4 public PartitionedTridentSpoutExecutor(IPartitionedTridentSpout spout) ( 
5 _spout = spout; 
6 } 

7 

8 


public IPartitionedTridentSpout getPartitionedSpout() { 
9 return _spout; 
10 } 
11 
12 class Coordinator implements ITridentSpout.BatchCoordinator<Object> { 
13 private IPartitionedTridentSpout.Coordinator _coordinator; 
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14 

15 public Coordinator(Map conf, TopologyContext context) { 
16 coordinator = _spout.getCoordinator(conf, context); 
17 } 

18 


19 @Override 
20 public Object initializeTransaction(long txid, Object prevMetadata, Object currMetadata) { 


21 if(currMetadata!-null) { 

22 return currMetadata; 

23 } else { 

24 return coordinator.getPartitionsForBatch(); 
25 } 

26 } 

27 


28 @Override 
29 public boolean isReady(long txid) { 


30 return coordinator. isReady(txid) ; 

31 } 

32 } 

33 

34 static class EmitterPartitionState { 

35 public RotatingTransactionalState rotatingState; 

36 public ISpoutPartition partition; 

37 

38 public EmitterPartitionState(RotatingTransactionalState s, ISpoutPartition p) { 

39 rotatingState = s; 

40 partition = p; 

41 } 

42 } 

43 

44 class Emitter implements ITridentSpout.Emitter<Object> { 

45 private IPartitionedTridentSpout.Emitter emitter; 

46 private TransactionalState state; 

47 private Map<String, EmitterPartitionState» partitionStates = new HashMap«String, 
EmitterPartitionState»(); 

48 private int index; 

49 private int numTasks; 

50 

51 public Emitter(String txStateId, Map conf, TopologyContext context) { 

52 emitter = _spout.getEmitter(conf, context); 

53 State - TransactionalState.newUserState(conf, txStateId); 

54 _index = context.getThisTaskIndex(); 

55 _numTasks = context.getComponentTasks(context.getThisComponentId()).size(); 

56 } 

57 

58 Object _savedCoordinatorMeta = null; 

59 

60 

61 @Override 

62 public void emitBatch(final TransactionAttempt tx, final Object coordinatorMeta, 

63 final TridentCollector collector) { 

64 if( savedCoordinatorMeta == null || ! savedCoordinatorMeta.equals(coordinatorMeta)) { 

65 List<ISpoutPartition> partitions = _emitter.getOrderedPartitions(coordinatorMeta) ; 


66 _partitionStates.clear(); 
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67 List<ISpoutPartition> myPartitions = new ArrayList(); 

68 for(int i= index; i < partitions.size(); i+=_numTasks) { 

69 ISpoutPartition p = partitions.get(i); 

70 String id = p.getId(); 

71 myPartitions.add(p); 

72 _partitionStates.put(id, new EmitterPartitionState(new Rotating 

TransactionalState( state, id), p)); 

73 j 

74  emitter.refreshPartitions(myPartitions); 

75 _savedCoordinatorMeta = coordinatorMeta; 

76 } 

77 for(EmitterPartitionState s: partitionStates.values()) { 

78 RotatingTransactionalState state = s.rotatingState; 

79 final ISpoutPartition partition = s.partition; 

80 Object meta = state.getStateOrCreate(tx.getTransactionId(), 

81 new RotatingTransactionalState.StateInitializer() { 

82 @Override 

83 public Object init(long txid, Object lastState) { 

84 return emitter.emitPartitionBatchNew(tx, collector, partition, 
lastState); 

85 } 

86 DE 

87 // it's null if one of: 

88 // a) a later transaction batch was emitted before this, so we should skip 

this batch 
89 // b) if didn't exist and was created (in which case the StateInitializer 
was invoked and 

90 // it was emitted 

91 if(meta!-null) { 

92  emitter.emitPartitionBatch(tx, collector, partition, meta); 

93 } 

94 } 

95 } 

96 

97 @Override 

98 public void success(TransactionAttempt tx) { 

99 for(EmitterPartitionState state: _partitionStates.values()) { 

100 state. rotatingState.cleanupBefore(tx.getTransactionId()); 

101 } 

102 } 

103 

104 @Override 

105 public void close() { 

106 _state.close(); 

107 _emitter.close(); 

108 } 

109 } 

110 } 


a 第 1 行 初始 化 其 元 数据 类 型 为 Integer。 不 过 后 面 第 12 行 和 第 44 行 又 将 接口 中 的 元 数据 类 型 
均 实 现 为 0bject 类 型 ， 故 第 1 行 处 的 元 数据 类 型 应 为 0bject 类 型 。 
a 第 12~32 行 实现 了 BatchCoordinator 接 口 。 
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um 第 20~26 行 实现 了 initializeTransaction 方 法 。 注 意 如 果 参 数 currMetadata 不 为 空 ， 方 
法 则 直接 返回 。 由 于 只 有 当 事 务 进行 重 传 时 currMetadata 才 不 为 空 ， 因 此 这 保证 了 事务 
重 传 时 具有 相同 的 元 数据 。 如 果 currMetadata 为 空 ， 则 通过 getPartitionsForBatch 方 法 
获得 分 区 的 元 数据 ， 并 且 这 部 分 数据 应 该 是 稳定 的 。 

m 第 29~31 行 的 isReady 方 法 通过 调用 代理 的 isReady 方 法 来 实现 。 

O 第 62~95 行 实现 Emitter 的 emitBatch 方 法 ， 这 是 该 类 的 核心 。 第 64 行 对 输入 的 分 区 元 数据 
进行 判断 ， 若 为 空 或 者 发 生变 化 ， 则 更 新 ZooKeeper 中 存储 的 信息 。 注 意 ， 用 户 需 要 自 定 
义 equals 方 法 来 对 元 数据 coordinatorMeta 进 行 合理 的 比较 。 

口 第 65 行 调用 get0rderedPartitions 方 法 ,根据 当前 的 分 区 元 数据 获得 分 区 信息 ， 然 后 根据 
节点 的 TaskId 以 及 并 行 度 ， 将 分 区 均匀 地 分 配 到 每 个 节点 上 。_partitionStates 变 量 用 来 
保存 当前 节点 所 负责 的 分 区 。 注意 , 第 72 行 为 每 个 分 区 在 ZooKeeper 上 分 配 了 合理 的 位 置 ， 
以 存储 每 个 分 区 的 元 数据 。 目 录 结 构 为 : /spout-id/user/partition-id/txid。 这 也 表明 ， 事 务 
在 每 个 分 区 上 都 会 有 一 个 事务 号 与 其 相对 应 。 

a 第 74 行 调用 refreshPartitions 方 法 ,用户 可 以 根据 分 区 的 情况 来 更 新 自身 的 数据 。 例 如 ， 

对 Kafka Queue Brokers 的 连接 ， 等 等 。 

O 第 77~94 行 依次 对 该 节点 所 负责 的 每 一 个 分 区 进行 处 理 。 第 80~86 行 较为 复杂 ， 若 事务 是 
重 传 的 ， 则 元 数据 meta 为 事务 第 1 次 初始 化 时 产生 的 的 值 ， 进 一 步 如 果 getState0rCreate 
返回 值 不 为 空 ， 则 直接 调用 emitpPartitionBatch 方 法 进行 重 传 。 若 事务 不 是 重 传 的 ， 则 利 
用 第 83 行 定义 的 init 函 数 对 事务 进行 初始 化 , emitPartitionBatchNew 需 要 产后 元 数据 。 这 
里 可 以 复 用 emitpPartitionBatch 的 实现 ， 返 回 值 会 被 作为 元 数据 进行 存储 。 

a 第 87~90 行 的 注释 很 有 趣 。 在 模糊 事务 类 型 的 Spout 中 ， 事 务 的 初始 化 并 不 要 求 强 序 ， 这 使 
得 后 面 的 事务 可 以 先 于 当前 事务 完成 , 即 当前 事务 的 数据 已 经 被 后 一 个 事务 完成 了 。 此 时 ， 
Trident 需 要 将 当前 事务 忽略 掉 。 在 IPartitionedTridentSpout 中 不 会 发 生 这 种 情况 。 

口 对 于 分 区 发 生变 更 并 且 分 区 数目 减少 的 情况 ， 目 前 的 系统 实现 在 有 些 时 候 会 导致 上 一 个 
事务 的 数据 不 能 被 正确 清理 。 例 如 处 理 顺 序 为 P1, P2, S1, S2，P1 代 表 事 务 1 的 处 理 阶 段 ， 
而 S1 代 表 事 务 1 的 提交 阶段 ， 依 此 类 推 。 若 处 理 P2 时 数据 的 分 区 数目 减少 ， 
_partitionStates 已 经 被 更 新 为 新 的 分 区 信息 ,等 到 再 去 调用 S1 时 ,删除 的 分 区 已 经 不 在 
_partitionStates 中 了 ， 此 时 第 98~102 行 代码 将 无 法 对 元 数据 进行 正确 清理 。 

可 以 看 出 , 该 类 是 在 Emitter 第 一 次 遇 到 某 个 事务 时 创建 的 相应 元 数据 ， 由 于 各 个 Emitter 

负责 的 分 区 没有 交集 ， 因 此 对 于 操作 ZooKeeper 是 安全 的 。 


17.5 ”模糊 事务 类 型 的 Spout 节点 
类 似 于 基本 模糊 事务 类 型 的 Spout 节 点 ，Trident 中 同样 含有 支持 模糊 事务 类 型 的 机 制 。 
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17.5.4 模糊 事务 类 型 的 Spout 接口 


IOpaquePartitionedTridentSpout 接 口 用 于 模糊 事务 类 型 Spout， 即 每 个 事务 对 应 的 元 数据 在 
同一 事务 的 不 同 尝试 之 间 是 可 以 不 同 的 。 它 的 接口 与 IPartitionedTridentSpout 基 本 相同 ， 元 数 
据 的 意义 也 是 相同 的 。 


public interface IOpaquePartitionedTridentSpout«Partitions, Partition extends ISpoutPartition, 
M» extends Serializable { 
public interface Coordinator«Partitions» ( 
boolean isReady(long txid); 
Partitions getPartitionsForBatch(); 
void close(); 


} 


public interface Emitter<Partitions, Partition extends ISpoutPartition, M> { 

/** 

* Emit a batch of tuples for a partition/transaction. 

* 

* Return the metadata describing this batch that will be used as lastPartitionMeta 
* for defining the parameters of the next batch. 

*/ 
M emitPartitionBatch(TransactionAttempt tx, TridentCollector collector, Partition 

partition, M lastPartitionMeta); 


/** 
* This method is called when this task is responsible for a new set of partitions. 
Should be used 

* to manage things like connections to brokers. 

A 

void refreshPartitions(List«Partition» partitionResponsibilities); 

List«Partition» getOrderedPartitions(Partitions allPartitionInfo); 

void close(); 


} 


Emitter<Partitions, Partition, M> getEmitter(Map conf, TopologyContext context) ; 
Coordinator getCoordinator(Map conf, TopologyContext context); 

Map getComponentConfiguration() ; 

Fields getOutputFields(); 


} 
Emitter 接 口中 只 含有 emitPartitionBatch 方 法 ， 其 输入 参数 为 上 一 个 事务 所 对 应 的 元 数据 ， 
并 且 没 有 当前 事务 的 元 数据 。 


17.5.2 ”模糊 事务 类 型 Spout 的 执行 器 


OpaquePartitionedTridentSpoutExecutor 2 K I f ICommitterTridentSpoutfz O, i2 BEL [n] 
Emitter 接 口中 新 增加 了 commit 方 法 。 实 现 了 ICommitterTridentSpout 接 口 的 节点 会 接收 Master 
Coordinator 的 $commit 流 ， 并 且 会 根据 从 该 流 收 到 的 消息 来 更 新 元 数据 。 理 解 何 时 产生 、 何 时 更 
新 元 数据 对 理解 这 个 Spout 是 非常 重要 的 。 
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本 节 主 要 分 析 一 些 关 键 方法 的 实现 ， 首 先 来 看 Coordinator 的 代码 : 


public class Coordinator implements ITridentSpout.BatchCoordinator«Object» { 
@Override 
public Object initializeTransaction(long txid, Object prevMetadata, Object currMetadata) { 
return coordinator.getPartitionsForBatch(); 


} 

在 BatchCoordinator 的 initializeTransaction 方 法 实现 中 ， 直 接 调 用 代理 的 _coordinator 的 
getPartitionsForBatch 方 法 来 获得 分 区 的 元 数据 ， 而 与 当前 的 元 数据 currMetadata 无 关 ， 这 使 得 
同一 个 事务 的 不 同 尝 试 可 以 对 应 于 不 同 的 分 区 。 

emitBatch 方 法 是 实现 该 接口 的 核心 实现 方法 ， 其 部 分 代码 与 上 一 节 中 的 Partitioned 
TridentSpoutExecutor 是 类 似 的 ， 本 节 主 要 讨论 它们 的 区 别 。 相 关 代码 如 下 : 


1 public class Emitter implements ICommitterTridentSpout.Emitter { 


2 @Override 

3 public void emitBatch(TransactionAttempt tx, Object coordinatorMeta, TridentCollector 
collector) { 

4 if( savedCoordinatorMeta--null || ! savedCoordinatorMeta.equals(coordinatorMeta)) { 

5 List<ISpoutPartition> partitions = _emitter.getOrderedPartitions(coordinatorMeta) ; 

6 _partitionStates.clear(); 

7 List<ISpoutPartition> myPartitions = new ArrayList(); 

8 for(int i= index; i < partitions.size(); i+=_numTasks) { 

9 ISpoutPartition p = partitions.get(i); 

10 String id = p.getId(); 

11 myPartitions.add(p) ; 

12 _partitionStates.put(id, new EmitterPartitionState(new Rotating 

TransactionalState(_state, id), p)); 

13 } 

14 _emitter.refreshPartitions(myPartitions) ; 

15 _savedCoordinatorMeta = coordinatorMeta; 

16 _changedMeta = true; 

17 } 

18 Map<String, Object> metas = new HashMap<String, Object>(); 

19 _cachedMetas.put(tx.getTransactionId(), metas); 

20 

21 Entry<Long, Map«String,Object»»entrys cachedMetas.lowerEntry(tx.getTransactionId()); 

22 Map«String, Object» prevCached; 

23 if(entry!-null) { 

24 prevCached = entry.getValue(); 

25 ) else { 

26 prevCached = new HashMap<String, Object>(); 

27 } 

28 

29 for(String id: _partitionStates.keySet()) { 

30 EmitterPartitionState s = _partitionStates.get(id); 

31 s.rotatingState.removeState(tx.getTransactionId()); 

32 Object lastMeta - prevCached.get(id); 

33 if(lastMeta--null) lastMeta = s.rotatingState.getlastState(); 

34 Object meta - emitter.emitPartitionBatch(tx, collector, s.partition, lastMeta); 


35 metas.put(id, meta); 
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36 } 

3 ] 

38 } 

Q 模糊 事务 类 型 的 Spout 中 , 事务 元 数据 并 不 是 在 调用 _emitter 的 emitPartitionBatch 方 法 时 
就 更 新 的 ， 而 是 需要 等 到 该 事务 已 经 被 提交 之 后 才能 更 新 ， 这 与 基础 的 模糊 事务 类 型 的 
设计 相 一 致 。 这 里 增加 了 _cachedMetas ， 用 来 存储 当前 遇 到 的 事务 的 元 数据 。 

口 第 18~19 行 清空 当前 事务 所 对 应 的 元 数据 。 

a 第 21~27 行 获得 前 一 个 事务 所 对 应 的 元 数据 ， 以 初始 化 lastMeta 变 量 。 

口 第 31 行 对 ZooKeeper 中 的 数据 进行 清理 。 如 果 事 务 重 传 ， 其 之 前 所 对 应 的 元 数据 都 是 无 效 
的 。 例 如 ， 在 提交 的 同时 ， 若 该 事务 已 经 超时 ， 则 元 数据 就 会 被 更 新 ， 但 事务 还 是 要 重 
新 来 做 的 。 

接 下 来 分 析 元 数据 是 何 时 被 更 新 的 。 commit 方 法 的 实现 如 下 : 


pum 


1 public void commit(TransactionAttempt attempt) { 

2 // this code here handles a case where a previous commit failed, and the partitions 

3 // changed since the last commit. This clears out any state for the removed partitions 

4 // for this txid. 

5 // we make sure only a single task ever does this. we're also guaranteed that 

6 // it's impossible for there to be another writer to the directory for that partition 

7 // because only a single commit can be happening at once. this is because in order for 

8 // another attempt of the batch to commit, the batch phase must have succeeded in between. 

9 // hence, all tasks for the prior commit must have finished committing (whether 
successfully or not) 

10 if( changedMeta 8&  index--0) ( 


11 Set«String» validIds = new HashSet<String>(); 

12 for(ISpoutPartition p: (List«ISpoutPartition») emitter.getOrderedPartitions 
( savedCoordinatorMeta)) { 

13 validIds.add(p.getId()); 

14 } 

15 for(String existingPartition: state.list("")) { 

16 if(!validIds.contains(existingPartition)) { 

17 RotatingTransactionalState s = new RotatingTransactionalState(_state, existing 

Partition); 

18 s.removeState(attempt.getTransactionId()); 

19 } 

20 } 

21 _changedMeta = false; 

22 } 

23 

24 Long txid = attempt.getTransactionId(); 

25 Map<String, Object» metas = _cachedMetas.remove(txid) ; 

26 for(String partitionId: metas.keySet()) { 

27 Object meta = metas.get(partitionId); 

28 _partitionStates.get(partitionId).rotatingState.overrideState(txid, meta); 

29 } 

30 } 


O 当 收 到 从 $commit 流 发 来 的 消息 时 ， 表 明 事务 的 处 理 阶段 已 经 结束 ， 事 务 提 交 Bolt 已 经 要 
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开始 调用 finishBacth 方 法 了 。 发 来 此 时 Trident 认 为 已 经 到 了 一 个 恰当 的 时 机 ， 可 以 去 更 

新 元 数据 到 ZooKeeper 中 ， 下 一 个 事务 的 处 理 可 以 基于 这 个 元 数据 来 进行 。 

O 当然 ， 在 事务 提交 了 Bolt 调用 finishBatch 方 法 时 ， 仍 然 可 以 将 事务 标记 为 失败 ， 这 种 情况 

下 事务 会 进行 重 传 。 由 于 事务 对 应 的 元 数据 是 可 以 变化 的 ,所 以 目前 的 设计 也 是 合理 的 。 

a 第 10~22 行 用 来 清理 ZooKeeper 中 的 数据 。 者 前 一 个 事务 在 处 理 阶段 成 功 ， 但 在 提交 时 失 
败 ， 同 时 下 一 个 事务 的 处 理 阶 段 已 经 开始 处 理 ， 则 此 时 分 区 的 元 数据 已 经 发 生 了 变化 。 
例如 ， 某 些 分 区 可 能 在 这 个 过 程 中 被 移 除 了 ， 即 最 新 的 _savedCoordinatorMeta 不 再 包含 
某 些 分 区 。 然 而 在 当前 的 事务 中 ,已 经 在 事务 处 理 阶 段 重新 将 元 数据 放 人 了 删除 的 分 区 。 
第 17~18 行 对 ZooKeeper 进 行 了 清理 。 第 10 行 的 条 件 意 为 若 分 区 的 元 数据 发 生变 化 ， 同 时 
保证 只 能 是 Task 编 号 为 第 一 的 节点 对 元 数据 进行 处 理 的 条 件 下 , 才 进 行 后 面 操作 。 多 个 市 
点 同时 删除 ZooKeeper 中 的 相同 节点 会 导致 异常 。 同 时 ，Trident 可 以 保证 当前 节点 只 有 一 
个 提交 发 生 。 


17.6 构建 Spout 节点 
Spout 节 点 在 Trident 中 对 应 于 一 个 新 的 流 。 本 节 分 析 Trident 如 何 创建 新 的 流 。 


17.6.1 TridentTopology 的 newStream 调用 


利用 传 入 的 ITridentSspout 类 型 的 Spout 节 点 ， 调 用 newStream 可 以 创建 一 个 新 的 流 。 在 Trident 中 
Spout 类 型 为 ITridentSpout， 其 他 类 型 的 Spout 会 被 适 配 成 为 ITridentSpout。newStream 的 代码 如 下 : 


1 public Stream newStream(String txId, IRichSpout spout) { 
2 return newStream(txId, new RichSpoutBatchExecutor(spout)); 


3j 
4 


5 public Stream newStream(String txId, IBatchSpout spout) ( 

6 Node n = new SpoutNode(getUniqueStreamId(), spout.getOutputFields(), txId, spout, 
SpoutNode. SpoutType. BATCH) ; 

7 return addNode(n); 


8 } 

9 

10 public Stream newStream(String txId, ITridentSpout spout) { 

11 Node n = new SpoutNode(getUniqueStreamId(), spout.getOutputFields(), txId, spout, 
SpoutNode. SpoutType. BATCH) ; 

12 return addNode(n) ; 

13 ] 

14 

15 public Stream newStream(String txId, IPartitionedTridentSpout spout) { 

16 return newStream(txId, new PartitionedTridentSpoutExecutor(spout)); 

17 ] 

18 

19 public Stream newStream(String txId, IOpaquePartitionedTridentSpout spout) { 

20 return newStream(txId, new OpaquePartitionedTridentSpoutExecutor(spout)); 


21 +} 
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第 10~13 行 对 应 的 是 真正 创建 节点 代码 ， 它 创建 了 一 个 Spout 节 点 。addNode 函 数 在 Trident 的 
Topology 中 创建 一 个 新 的 节点 。newStream 了 水 数 返 回 一 个 流 对 象 。 流 对 象 是 Trident 中 的 重要 概念 ， 
是 构建 Topology 的 基础 ， 后 面 我 们 将 对 其 进行 详细 讨论 。 

表 17-1 给 出 了 Spout 节 点 的 适 配 关 系 。 


表 17-1 Spout 节 点 类 的 适 配 关 系 


原始 Spout 类 型 适配器 或 执行 器 
IRichSpout RichSpoutBatchExecutor(spout) 
IBatchSpout BatchSpoutExecutor(spout) (TridentTopologyBuilder) 
IPartitionedTridentSpout PartitionedTridentSpoutExecutor(spout) 
IOpaquePartitionedTridentSpout OpaquePartitionedTridentSpoutExecutor(spout) 


17.6.2 TridentTopology  newDRPCStream 调用 


newDRPCStream 会 根据 输入 的 DRPCSpout 节 点 来 获得 一 个 流 。DRPC 技 术 主 要 用 于 查询 , 详情 请 
参见 第 25 章 。DRPC 流 中 的 Spout 节 点 较为 特殊 ,其 中 一 个 事务 中 只 含有 一 条 消息 。newDRPCStream 
的 代码 如 下 : 


1 public Stream newDRPCStream(String function) { 


2 return newDRPCStream(new DRPCSpout(function)); 
3 } 

4 

5 public Stream newDRPCStream(String function, ILocalDRPC server) { 
6 DRPCSpout spout; 

7 if(server--null) { 

8 spout = new DRPCSpout (function); 

9 } else { 

10 spout = new DRPCSpout(function, server); 
11 } 

12 return newDRPCStream(spout) ; 

13 } 

14 


15 private Stream newDRPCStream(DRPCSpout spout) { 

16 // TODO: consider adding a shuffle grouping after the spout to avoid so much 
routing of the args/return-info all over the place 

17 // (at least until its possible to just pack bolt logic into the spout itself) 


19 Node n = new SpoutNode(getUniqueStreamId(), TridentUtils.getSingleOutput 
StreamFields(spout), null, spout, SpoutNode.SpoutType.DRPC); 

20 Stream nextStream - addNode(n); 

21 // later on, this will be joined back with return-info and all the results 

22 return nextStream.project(new Fields("args")); 

23 ] 


a 第 15~23 行 代码 用 来 创建 一 个 DRPC 流 ，DRPC 流 中 包含 了 一 个 DRPC 的 Spout 节 点 。 
O 第 22 行 ， 在 得 到 DRPC 流 之 后 ， 添 加 一 个 映射 节点 ,该 节点 的 输出 只 有 args 列 。 


Trident 的 存储 


在 Storm 中 ，Spout 市 点 类 型 决定 了 Topology 的 类 型 ， 基 本 事务 Spout 节 点 以 及 模糊 事务 Spout 
节点 可 以 实现 消息 的 可 靠 传 输 , 但 并 不 能 保证 消息 仅 被 处 理 一 次 , 要 想 进一步 保证 这 一 点 ,就 需 
要 存储 的 支持 。 与 Spout 节 点 类 型 类 似 ， 存 储 也 可 以 分 为 三 种 类 型 。 图 18-1 给 出 了 Spout 节 点 类 型 
与 存储 类 型 的 对 应 关系 ， 以 及 它们 能 否 保 证 消息 的 “不 多 不 少 处 理 ” 这 一 语义 (该 图 源 自 Storm 
官方 网 站 )。 


Transactional 


Opaque 
transactional transactional 


Non- 
transactional 


No No 
Opaque 


图 18-1。 Spout 节点 与 存储 的 对 应 关系 


可 以 看 出 ， 即 便 使 用 事务 类 型 Spout 节 点 而 不 使 用 事务 类 型 的 存储 ， 同 样 是 不 可 能 实现 “不 乡 
不 少 的 数据 处 理 ”( Exactly Once ) 这 一 语义 的 ， 必 须要 Spout 节 点 与 存储 配合 使 用 才能 够 。 

注意 ，Storm 中 的 存储 并 不 是 Trident 特 有 的 概念 ， 但 由 于 其 实现 主要 在 Trident 的 命名 空间 中 
发 生 ， 故 本 书 将 其 与 Trident 一 起 讨论 。 


18.1 存储 的 基本 接口 


State 接 口 是 存 储 的 基本 接口 。 而 MapState 接 口 对 应 于 数据 为 哈 希 表 的 情况 ， 对 于 事务 
Topology， 通 常 将 事务 序号 作为 键 ， 事 务 的 处 理 结 果 作 为 值 ，MapState 接 口 更 利于 进行 重 操作 。 
基本 的 类 关系 如 图 18-2 所 示 。 
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) 
@multiput(List<List<Object>>, List<T>) void | imiltilpdate(ListcList<Object>», List«Valueupdater» )List<T> Updater) ListeT>) @multiUpdate(List<List<Object>>, List<ValueUpdaters) | smultiUp 
®beginConmit (long) Liste» 


gi 8) void) GmultiPut (List<List<Object>>, Liste») void) jmultiput(List<List<Object>>, ListcT»)void eup > 
‘commit (Long) void | sibeginCommit(Long) void gcache(List<List<Object>>,List<T>) void) gmultiPut(ListcList«Object»», List«T») void) @multiPut(List<List<Object>>,List<T>) voi 
iget() T| s&comit(1ong) void| ss beginCommit(Long) void) jbeginConmit(Long) void! jbeginConmit (Long) 
is m d "i commit (Long) void) sscomit(Long) void scommit(Long) 

voi 


图 18-2 ”State 接 口 的 类 关系 
下 面 讨论 State 接 口 以 及 MapState 接 口 ， 相 关 代码 如 下 : 


public interface State { 


void beginCommit(Long txid); // can be null for things like partitionPersist occuring off a DRPC 
stream 


void commit(Long txid); 


} 


public interface ReadOnlyMapState<T> extends State { 


// certain states might only accept one-tuple keys - those should just throw an error 
List<T> multiGet(List<List<Object>> keys); 


} 


public interface MapState<T> extends ReadOnlyMapState<T> { 
List<T> multiUpdate(List<List<Object>> keys, List«ValueUpdater» updaters); 
void multiPut(List<List<Object>> keys, List<T> vals); 


} 

O State 接 口中 定义 了 两 个 方法 : peginCommit 用 来 表示 开始 更 新 一 个 事务 所 对 应 的 数据 ， 

commit 方 法 则 表示 完成 了 对 一 个 事务 的 更 新 。 

口 并 不 是 每 一 种 存储 的 实现 都 需要 用 到 这 两 个 方法 , 例如 在 非 事务 类 型 的 Topology 中 , 数据 
将 直接 写 和 人 ， 并 不 需要 调用 beginCommit 以 及 commit 这 两 个 方法 。 不 过 ， 这 两 个 方法 提供 
了 事务 开始 和 结束 的 调用 时 间 点 。 

O 基本 State 接 口中 并 未 定义 如 何 去 更 新 数据 ， 于 是 在 ReadonlyMapState 接 口中 定义 了 一 个 

multiGet 方 法 。 它 的 输入 为 List<Object> 作 为 键 的 一 组 查询 ， 输 出 为 这 些 键 对 应 的 值 。 

口 在 MapState 接 口中 , 额外 的 定义 了 multiupdate 和 multiput 方 法 用 于 批量 写 入 。 目前, Storm 
中 主要 实现 了 MapState 接 口 。 


18.2 MapState 接口 的 实现 
MapSstate 接 口 是 Storm 中 的 重要 接口 ， 本 节 将 分 析 该 接口 中 相对 重要 实现 。 
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18.2.1 非 事 务 类 型 的 存储 


NonTiransactionalMap 实 现 了 MapState 接 口 ， 它 也 是 MapSstate 的 最 简单 实现 ， 用 于 非 事务 的 情 
况 。 其 代码 如 下 : 


public class NonTransactionalMap«T» implements MapState«T» { 
public static «T» MapState«T» build(IBackingMap<T> backing) { 
return new NonTransactionalMap«T» (backing); 
} 


1 
2 
3 
4 
5 
6 IBackingMap«T» backing; 
7 
8 
9 
1 


protected NonTransactionalMap(IBackingMap«T» backing) { 
backing - backing; 
o J 
11 
12  QOverride 
13 public List<T> multiGet(List<List<Object>> keys) { 
14 return _backing.multiGet (keys) ; 
15 } 
16 
17  QOverride 
18 public List<T> multiUpdate(List«List«Object»» keys, List«ValueUpdater» updaters) { 


19 List<T> curr = backing.multiGet(keys); 

20 List<T> ret = new ArrayList<T>(curr.size()); 
21 for(int i-0; i«curr.size(); i++) ( 

22 T currVal = curr.get(i); 

23 ValueUpdater«T» updater - updaters.get(i); 
24 ret.add(updater.update(currVal)); 

25 

26  backing.multiPut(keys, ret); 

27 return ret; 

28 ] 

29 


30  QOverride 

31 public void multiPut(List«List«Object»» keys, List<T> vals) { 
32  backing.multiPut(keys, vals); 
33 ] 

34 

35  QOverride 

36 public void beginCommit(Long txid) ( 
3 ] 

38 

39  QOverride 

40 public void commit(Long txid) { 

41 jJ 

42 } 


O 第 6 行 ，IBackingMap<T> 类 型 的 backing 变 量 用 于 实际 存储 数据 。 

O 第 2~4 行 的 静态 build 方 法 将 传人 一 个 IBackingMap 类 型 的 对 象 , 并 构建 一 个 NonTransactionalMap 
对 象 。 用户 可 以 自己 实现 新 的 I1BackingMap 对 象 , 例如 ,大 用 户 实现 了 一 个 基于 文件 或 者 数 
据 库 的 IBackingMap 对 象 ， 那 么 数据 将 会 被 存储 到 文件 或 者 数据 库 中 。 
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C NonTransactionalMap 中 beginCommit 和 commit 的 实现 为 空 。 
口 第 18~28 行 实现 multiUpdate 方 法 ， 首 先 看 一 下 输入 参数 的 意义 。 

m keys: List<Object> 作 为 键 ， 输 入 为 一 组 键 值 。 

m updaters: 每 一 个 键 都 对 应 于 这 里 的 一 个 ValueUpdater 对 象 。updaters 的 
数目 相同 。ValueUpdater 接 口 用 来 表示 如 何 对 已 经 存在 值 进行 更 新 , 通常 
更 新 算法 。ValueUpdater 接 口 是 Trident 对 数据 更 新 的 抽象 ， 本 章 其 他 小 节 
细 讨 论 。 

a 第 19 行 调用 存储 对 象 backing 的 multiGet 方 法 获得 与 键 相 对 应 的 当前 值 。 


计算 得 到 更 新 后 的 值 。 

口 第 26~27 行 将 数据 重新 写 回 到 _backing 中 ， 并 返回 更 新 后 的 值 。 

口 目前 的 实现 中 并 未 对 输入 和 输出 进行 检查 ， 例 如 若 输 入 为 5 个 键 , 在 第 19 行 
时 并 不 一 定 能 保证 返回 5 个 值 , 这 将 导致 不 正确 的 状态 。 所 以 在 IBackingMap 
注意 返回 值 的 数目 。 


18.2.2 事务 类 型 的 存储 


数目 与 keys 的 
它 会 含有 一 个 
将 对 其 进行 详 


口 第 20~25 行 获得 相应 的 ValueUpdater 以 及 当前 值 , 然后 通过 调用 ValueUpdater 的 update 方 法 


去 获取 当前 值 
的 实现 中 需要 


TransactionalMap 对 应 于 事务 Topology 中 的 事务 Spout， 即 同一 个 事务 一 定 对 应 
数据 。 该 类 的 代码 如 下 : 


1 public class TransactionalMap«T» implements MapState<T> { 

2 public static «T» MapState«T» build(IBackingMap«TransactionalValue» backing) { 
3 return new CachedBatchReadsMap«T» (new TransactionalMap<T>(backing)) ; 
4] 

5 

6 IBackingMap«TransactionalValue» backing; 

7 Long currTx; 

8 

9 protected TransactionalMap(IBackingMap«TransactionalValue» backing) { 

10 backing - backing; 

11 } 

12 


13 @Override 
14 public List<T> multiGet(List<List<Object>> keys) { 


15 List«TransactionalValue» vals = _backing.multiGet (keys) ; 
16 List<T> ret = new ArrayList<T>(vals.size()); 
17 for(TransactionalValue v: vals) { 

18 if(v!=null) { 

19 ret.add((T) v.getVal()); 

20 } else { 

21 ret.add(null); 

22 

23 } 

24 return ret; 

25 } 


着 同样 的 一 组 
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27 @Override 
28 public List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters) { 
29 List<TransactionalValue> curr = _backing.multiGet (keys) ; 
30 List<TransactionalValue> newVals = new ArrayList<TransactionalValue>(curr.size()); 
31 List<T> ret = new ArrayList<T>(); 
32 for(int i=0; i«curr.size(); i++) ( 
33 TransactionalValue<T> val = curr.get(i); 
34 ValueUpdater<T> updater = updaters.get(i); 
35 TransactionalValue<T> newVal; 
36 if(val==null) { 
37 newVal = new TransactionalValue<T>(_currTx, updater.update(null)); 
38 } else { 
39 if(_currTx!=null 8& _currTx.equals(val.getTxid())) { 
40 newVal = val; 
41 } else { 
42 newVal = new TransactionalValue<T>(_currTx, updater .update(val.getVal())); 
43 } 
44 } 
45 ret.add(newVal.getVal()); 
46 newVals.add(newVal); 
47 
48 _backing.multiPut(keys, newVals); 
49 return ret; 
50 } 
51 
52 @Override 
53 public void multiPut(List<List<Object>> keys, List<T> vals) { 
54 List<TransactionalValue> newVals = new ArrayList<TransactionalValue>(vals.size()); 
55 for(T val: vals) { 
56 newVals.add(new TransactionalValue<T>(_currTx, val)); 
57 } 
58 _backing.multiPut(keys, newVals); 
59} 
60 
61 GOverride 
62 public void beginCommit(Long txid) { 
63 _currTx = txid; 
64 } 
65 
66 @Override 
67 public void commit(Long txid) { 
68 _currTx = null; 
69 } 
70 } 


口 TransactionalMap 含 有 两 个 成 员 变 量 。 


_backing。IBackingMap<TransactionalValue> 类 型 。 其 中 核心 为 TransactionalValue 类 ， 
该 类 的 定义 如 下 : 
public class TransactionalValue<T> { 

T val; 

Long txid; 


} 
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其 中 val 为 通用 类 型 ， 为 事务 处 理 的 结果 ，txid 为 事务 序号 ， 所 以 TransactionalValue 
表示 为 txid 所 对 应 的 值 。 
m _currTx 表 示 当 前 的 事务 序号 。 

口 第 28~50 行 实现 multiUpdate 方 法 ， 该 方法 是 TransactionalMap 的 核心 方法 。 

a 第 36~38 行 对 应 于 当前 值 为 空 的 情况 ， 此 时 将 把 ValueUpdater 中 含有 的 值 作为 返回 值 ， 并 

与 当前 的 事务 序号 _currTx 做 比较 。 

O 第 39~43 行 ， 若 当前 的 _currTx 与 当前 值 中 的 事务 序号 相同 ， 则 直接 将 val 赋 值 给 newVal , 
表示 并 不 对 当前 的 值 进 行 更 新 。 这 时 每 个 事务 所 对 应 的 数据 是 相同 的 。 若 _currTx 与 当前 
值 中 的 txid 不 同 , 则 调用 ValueUpdater 的 update 方 法 进行 更 新 ,由 于 只 有 在 实现 了 ICommiter 
的 Bolt 中 才能 保证 事务 序号 的 强 序 关 系 , 通常 TransactionalMap 只 能 用 在 事务 提交 Bolt 中 。 

口 第 61~64 行 实现 beginCommit 方 法 ,将 _currTx 设 置 为 输入 值 ， 该 方法 会 在 一 个 事务 开始 时 

被 调用 。 

a 第 67~69 行 实现 commit 方 法 ,将 _currTx 置 为 空 ， 该 方法 会 在 一 个 事务 结束 时 被 调用 。 
注意 ,multiUpdate 需 要 将 一 个 事务 所 对 应 的 数据 同时 传人 。 其 他 的 方法 都 是 比较 直观 的 ， 
这 里 不 再 一 一 讨论 。 


18.2.3 ”模糊 事务 类 型 存储 


0paqueMap 对 应 于 事务 Topology 中 的 模糊 事务 Spout 节 点 ， 表 示 同 样 的 事务 并 不 一 定 对 应 相同 


的 数据 ， 但 是 同一 条 消息 一 定 只 属于 某 一 个 事务 。 下 面 首 先 看 一 下 0paqueValue 的 定义 及 主要 方 


法 ， 


它 是 0paqueMap 中 存储 的 值 ，0paqueValue 的 代码 如 下 : 


1 public class OpaqueValue<T> { 

2 Long currTxid; 

3 T prev; 

4 T curr; 

5 

6 public OpaqueValue(Long currTxid, T val, T prev) ( 

7 this.curr - val; 

8 this.currTxid - currTxid; 

9 this.prev - prev; 

10 } 

11 

12 public OpaqueValue<T> update(Long batchTxid, T newVal) { 
13 T prev; 

14 if(batchTxid!-null 8& batchTxid.equals(this.currTxid)) { 
15 prev = this.prev; 

16 } else { 

17 prev = this.curr; 

18 } 

19 return new OpaqueValue<T>(batchTxid, newVal, prev); 
20 } 

21 


22 public T get(Long batchTxid) { 
23 if(batchTxid!-null 8& batchTxid.equals(currTxid)) { 
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24 return prev; 
25 ) else { 

26 return curr; 
27 } 

28 } 

29 } 


O 与 TransactionalValue 相 似 ，0paqueValue 含 有 txid、 代 表 当 前 值 的 curr， 额 外 的 prev 表 示 

前 一 个 事务 所 对 应 的 值 。 

口 第 12~20 行 定义 update 方 法 ， 这 里 curr 都 会 被 更 新 为 newVal， 主 要 看 如 何 处 理 prev 的 值 。 
若 batchTxid 与 当前 的 currTxid 相 同 ， 表 示 一 个 事务 进行 了 重 传 ， 因 此 不 更 新 prev 的 值 ; 
否则 就 将 当前 值 curr 赋 值 给 prev。 

OpaqueMap 的 方法 实现 与 TransactionalMap 的 方法 实现 类 似 ， 这 里 主要 分 析 一 下 其 中 的 
multi _ Update 方法， 相关 代码 如 下 : 


1 public class OpaqueMap<T> implements MapState<T> { 

2 @Override 

3 public List<T> multiUpdate(List<List<Object>> keys, List<ValueUpdater> updaters) { 
4 List<OpaqueValue> curr = _backing.multiGet (keys) ; 

5 List<OpaqueValue> newVals = new ArrayList<OpaqueValue>(curr.size()); 

6 List<T> ret = new ArrayList<T>(); 

7 for(int i=0; i«curr.size(); i++) ( 

8 OpaqueValue<T> val = curr.get(i); 


9 ValueUpdater<T> updater = updaters.get(i); 
10 T prev; 

11 if(val==null) { 

12 prev = null; 

13 } else { 

14 prev = val.get(_currTx); 

15 } 

16 T newVal = updater.update(prev) ; 

17 ret.add(newVal); 

18 OpaqueValue«T» newOpaqueVal; 

19 if(val==null) { 

20 newOpaqueVal = new OpaqueValue<T>(_currTx, newVal); 
21 } else { 

22 newOpaqueVal = val.update(_currTx, newVal); 
23 

24 newVals.add(newOpaqueVal); 

25 

26 _backing.multiPut(keys, newVals); 

27 return ret; 

28 } 

29 } 


O 第 10~15 行 获得 当前 的 prev 值 。 

a 第 16~17 行 调用 updater 的 update 方 法 获得 newval， 并 将 其 放 入 到 返回 值 中 。 

O 第 19~24 行 获得 new0paqueVal， 其 中 调用 了 0paqueValue 的 update 方 法 以 完成 更 新 。newVal 
与 new0paqueVal 中 curr 值 是 相同 的 ， 区 别 反 在 于 如 何 更 新 prev 的 值 。 
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18.3 值 的 序列 化 方法 
本 节 讨 论 与 存储 对 应 的 3 种 值 类 型 的 序列 化 方法 。Trident 定 义 了 Serializer 接 口 ,其 代码 如 下 : 


public interface Serializer«T» extends Serializable ( 
byte[] serialize(T obj); 
T deserialize(byte[] b); 

} 


用 于 对 TransactionalValue 、NonTransactionalValue 和 0paqueValue 进 行 序列 化 的 类 列举 如 下 。 
口 JSONNonTransactionalSerializer: 用 于 序列 化 通用 类 型 T。 

口 JSONOpaqueSerializer: 用 于 序列 化 0paqueValue 类 。 

口 JSONTransactionalSerializer: 用 于 序列 化 TransactionalValue 类 。 

下 面 简单 分 析 一 下 JSONOpaqueSerializer: 


public class JSONOpaqueSerializer implements Serializer«OpaqueValue» { 


@Override 
public byte[] serialize(OpaqueValue obj) { 
List toSer = new ArrayList(3); 
toSer.add(obj.currTxid) ; 
toSer.add(obj.curr) ; 
toSer.add(obj.prev) ; 
try { 
return JSONValue.toJSONString(toSer).getBytes("UTF-8"); 
} catch (UnsupportedEncodingException e) { 
throw new RuntimeException(e); 


} 
} 
@Override 
public OpaqueValue deserialize(byte[] b) { 
try { 
String s = new String(b, "UTF-8"); 
List deser - (List) JSONValue.parse(s); 
return new OpaqueValue((Long) deser.get(0), deser.get(1), deser.get(2)); 
} catch (UnsupportedEncodingException e) { 
throw new RuntimeException(e); 
} 
} 


} 


口 serialize 的 实现 方法 中 , 将 currTxid、curr 和 prev 放 置 于 列表 里 , 然后 利用 JSON 将 其 序列 化 。 
口 deserialize 的 实现 方法 中 ， 利 用 JSON 反 序列 化 得 到 列表 ， 然 后 构建 0OpaqueValue 对 象 。 

a JSON 序 列 化 的 结果 是 较为 直观 的 , 不 过 由 于 JSON 序 列 化 以 及 反 序 列 化 的 效率 较 低 , 实际 
应 用 中 通常 采用 更 为 高 效 的 序列 化 方法 。 
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18.4 数据 更 新 接口 


Trident 中 采用 ValueUpdater 接口 对 存储 的 更 新 操作 进行 抽象 : 


public interface ValueUpdater<T> { 
T update(T stored); 


其 update 方 法 的 输入 参数 为 通用 类 型 T，stored 表 示 更 新 前 的 值 ， 返 回 值 为 更 新 后 的 值 。 
ValueUpdater 通 常 内 含 更 新 算法 及 输入 。 类 关系 如 图 18-3 所 示 。 


I ValueUpdater 
mupdate(T) T 
à & 


c CombinerValueUpdater 
mupdate(Object) Object 


© ReducerValueUpdater 
m) update(Object) Object 


图 18-3 ”数据 更 新 接口 的 类 关系 


18.4.1 CombinerValueUpdater 
CombinerValueUpdater 实 现 了 ValueUpdater 接 口 ， 其 代码 如 下 : 


public class CombinerValueUpdater implements ValueUpdater«Object» { 
Object arg; 
CombinerAggregator agg; 


public CombinerValueUpdater(CombinerAggregator agg, Object arg) ( 
this.agg - agg; 
this.arg - arg; 


@Override 
public Object update(Object stored) { 
if(stored==null) return arg; 
else return agg.combine(stored, arg); 
} 
} 


口 CombinerValueUpdater 内 含 一 个 CombinerAggregator 类 型 的 agg 成 员 变 量 。update 方 法 的 输 
人 参数 stored 表 示 当 前 值 , 类 成 员 变量 arg 表 示 当 前 输入 更 新 值 。update 方 法 会 根据 stored 
和 azrg 产 生 一 个 新 的 值 ， 若 当前 stored 值 为 空 ， 则 直接 返回 arg 值 ， 和 否则 调用 agg 的 combine 
THE. 
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口 CombinerValueUpdater 中 既 包含 了 算法 ， 又 包含 了 将 要 用 于 更 新 的 值 。 


18.4.2 ReducerValueUpdater 


ReducerValueUpdater 类 与 CombinerValueUpdater 类 似 ， 它 内 含 一 个 ReducerAggregator 类 型 的 
成 员 变 量 agg， 以 及 将 要 被 用 于 更 新 的 TridentTuple 消 息 集合 。 该 类 的 代码 如 下 : 


public class ReducerValueUpdater implements ValueUpdater«Object» { 
List«TridentTuple» tuples; 
ReducerAggregator agg; 


public ReducerValueUpdater(ReducerAggregator agg, List«TridentTuple» tuples) { 
this.agg - agg; 
this.tuples - tuples; 


} 


@Override 
public Object update(Object stored) { 
Object ret = stored; 
for(TridentTuple t: tuples) { 
ret = this.agg.reduce(ret, t); 


} 


return ret; 
} 
} 


O 在 update 的 实现 方法 中 ， 依 次 调用 了 ReducerAggregator 的 reducer 方 法 。 
口 本 书 会 在 其 他 音节 分 析 Aggregator 和 Combiner 的 接口 及 实现 。 


18.5 ”存储 更 新 接口 


StateUpdater 接 口 用 来 对 存储 的 更 新 操作 进行 抽象 。 而 ValueUpdater 则 更 为 细 粒 度 ， 它 是 对 
存储 中 每 一 个 具体 值 的 更 新 操作 进行 抽象 。 存 储 更 新 接口 及 其 实现 类 的 关系 如 图 18-4 所 示 。 


1 Operation 


c BaseOperation 1 StateUpdater 


上 1 1 1 
c BaseStateUpdater| c NapReducerAggStateUpdater | c ReducerAggStateUpdater | € MapCombinerAggStateUpdater| | c CombinerAggStateUpdater 


图 18-4 存储 更 新 接口 的 类 关系 


存储 更 新 接口 的 定义 分 析 如 下 ， 该 接口 继承 自 operation 接 口 。0peration 接 口 将 在 其 他 章节 
进行 讨论 ， 它 代表 了 Trident 对 操作 的 抽象 。 
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public interface StateUpdater«S extends State» extends Operation { 
void updateState(S state, List«TridentTuple» tuples, TridentCollector collector); 
} 


该 接口 定义 了 updatestate 方 法 ， 其 输入 参数 分 析 如 下 。 
O state: 实现 State 接 口 的 对 象 ， 表 示 要 进行 更 新 的 State 对 象 。 
口 tuples: 输入 的 TridentTuple 消 息 列表 。 
口 collector: TridentOutputCollector 对 象 ， 用 于 发 送 数据 。 
相关 的 类 实现 中 通常 会 使 用 相应 的 ValueUpdater 对 和 象 ， 然 后 将 其 作为 参数 调用 存储 的 
multiUpdate 方 法 。 


18.5.1 ReducerAggStateUpdater 


ReducerAggStateUpdater 实现 了 StateUpdaer 接口 ， 其 代码 如 下 : 


public class ReducerAggStateUpdater implements StateUpdater<Snapshottable> { 
ReducerAggregator agg; 


public ReducerAggStateUpdater(ReducerAggregator agg) { 
-3a88 = agg; 


@Override 


public void updateState(Snapshottable state, List<TridentTuple> tuples, TridentCollector collector) { 
Object newVal = state.update(new ReducerValueUpdater( agg, tuples)); 
collector.emit(new Values(newVal)); 


】 
} 


O ReducerAggStateUpdater 中 含有 一 个 ReducerAggregator 类 型 的 agg Œ. 在 updateState 的 
实现 方法 中 创建 了 RecuderValueUpdater 对 象 , 然后 调用 存储 的 update 方 法 。 agg 将 依次 对 
输入 的 消息 调用 aggregate 方 法 ， 并 将 最 终 的 结果 存储 在 存储 对 象 中 。 

O ReducerAggStateUpdater 最 终 会 将 得 到 的 消息 发 送出 去 。 

口 CombinerAggStateUpdater 与 ReducerAggStateUpdater 的 实现 很 类 似 ， 只 不 过 它 的 _agg 为 Combiner 
Aggregator 类 型 ， 其 内 部 利用 CombinerValueUpdater 根 据 输入 的 消息 对 State 进 行 更 新 。 


18.5.2 MapReducerAggStateUpdater 


MapReducerAggStateUpater 主 要 用 于 分 组 聚集 操作 (Group By ) 之 后 对 分 组 的 结果 进行 更 新 ， 
它 进 行 聚集 的 键 为 分 组 的 列 。 该 类 的 代码 如 下 : 


1 public class MapReducerAggStateUpdater implements StateUpdater«MapState» { 
2 ReducerAggregator agg; 

3 Fields groupFields; 

4 Fields inputFields; 

5 ProjectionFactory groupFactory; 
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6 ProjectionFactory _inputFactory; 

7 ComboList.Factory factory; 

8 

9 

10 public MapReducerAggStateUpdater(ReducerAggregator agg, Fields groupFields,Fields inputFields) { 
11 .8388 = 9883 

12 _groupFields = groupFields; 

13 _inputFields = inputFields; 

14 _factory = new ComboList.Factory(groupFields.size(), 1); 
15  } 

16 

17 


18 @Override 


19 public void updateState(MapState map, List<TridentTuple> tuples, TridentCollector collector) { 


20 Map<List<Object>, List<TridentTuple>> grouped = new HashMap(); 

21 

22 List<List<Object>> groups = new ArrayList<List<Object>>(tuples.size()); 
23 List<Object> values = new ArrayList<Object>(tuples.size()); 

24 for(TridentTuple t: tuples) { 

25 List<Object> group = _groupFactory.create(t); 

26 List<TridentTuple> groupTuples = grouped.get(group) ; 

27 if(groupTuples==null) { 

28 groupTuples = new ArrayList(); 

29 grouped.put(group, groupTuples) ; 

30 } 

31 groupTuples.add(_inputFactory.create(t)); 

32 } 

33 List<List<Object>> uniqueGroups = new ArrayList (grouped.keySet()); 
34 List<ValueUpdater> updaters = new ArrayList(uniqueGroups.size()); 

35 for(List<Object> group: uniqueGroups) { 

36 updaters.add(new ReducerValueUpdater( agg, grouped.get(group))); 
37 } 

38 List<Object> results = map.multiUpdate(uniqueGroups, updaters); 

39 

40 for(int i=0; i<uniqueGroups.size(); i++) ( 

41 List<Object> group = uniqueGroups.get(i); 

42 Object result = results.get(i); 

43 collector.emit(_factory.create(new List[] {group, new Values(result) })); 
44 } 

45 } 

46 


47 @Override 


48 public void prepare(Map conf, TridentOperationContext context) { 


49 _groupFactory = context.makeProjectionFactory(_groupFields) ; 
50 _inputFactory = context.makeProjectionFactory(_inputFields) ; 
51 } 

52 } 


Q groupFields: 进行 分 组 的 字段 名 。 
口 _groupFactory: ProjectionFactory 类 型 ， 
Q inputFileds: 输入 消息 的 字段 名 。 


口 _agg: ReducerAggregator 类 型 对 象 ， 表 示 为 聚集 算法 。 


根据 _groupFields 来 映射 消 ， 


H 


USO 
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口 inputFactory: ProjectionFactory 类 型 ， 根 据 _inputFields 映 射 消息 。 

口 _factory: ComboList.Factory 对 和 象 。 由 两 个 部 分 构成 ， 一 部 分 为 _ groupFields ， 另 外 一 部 

分 为 分 组 的 结果 ， 目 前 的 结果 是 只 能 有 1 列 。 

O 第 19~45 行 实现 updateSstate 方 法 。 第 22~23 行 定义 的 局 部 变量 目前 没有 被 用 到 。 第 20 行 定 
义 局 部 变量 grouped 用 来 存储 按照 groupFields 进 行 分 组 的 消息 , 它 的 键 为 groupFields, fH 
为 具有 相同 groupFields 的 消息 集合 。 第 24~32 行 将 输入 的 消息 按照 groupFields 进 行 分 组 。 

O 第 33~37 行 根据 分 组 的 个 数 创建 相应 的 ValueUpdater， 每 一 个 分 组 对 应 一 个 ValueUpdater。 
ReducerValueUpdater 的 输入 为 ReducerAggregator 对 象 以 及 属于 该 分 组 的 消息 集合 。 该 
_agg 将 对 此 集合 依次 调用 aggregate 方 法 ， 结 果 被 存储 于 存储 对 象 中 。 第 38 行 调用 
multiUpdate 方 法 。 第 40~44 行 将 结果 消息 输出 。 

口 MapReducerAggStateUpater 与 ReducerAggStateUpdater 的 区 别 在 于 : 前 者 是 对 MapState 接 口 
进行 操作 的 ， 它 的 键 为 分 组 域 ， 而 后 者 更 为 通用 ， 是 对 Snapshottable 接 口 进行 操作 的 ， 
没有 键 的 概念 。 

口 MapCombinerAggStateUpdater 与 MapReducerAggStateUpater 的 实现 类 似 ， 只 不 过 它 的 _agg 为 
CombinerAggregator 类 型 ， 内 部 利用 CombinerValueUpdater 按 照 输 入 的 消息 对 存储 进行 更 新 。 


18.5.3 BaseStateUpdater 


BaseStateUpdater 同 时 实现 了 Base0peration 和 StateUpdater 两 个 接口 ， 目 前 还 仅仅 处 于 想法 
阶段 ， 并 没有 实际 使 用 。 目 前 StateUpdate 的 实现 基本 上 是 批 处 理 模式 的 ， 即 当 一 个 事务 处 理 结 
束 之 后 才 统 一 进行 更 新 ， 那么 可 不 可 以 逐步 地 对 存储 对 象 进 行 更 新 呢 ? 这 样 设 计 才 使 得 State 接 
口中 beginCommit 方 法 和 commit 方 法 更 具 意义 。 这 可 能 是 Storm 未 来 会 改进 的 地 方 。 


18.6 创建 存储 对 象 
StateFactory 接 口 对 如 何 创建 一 个 state 对 象 进行 了 抽象 ， 相 关 代码 如 下 : 


public interface StateFactory extends Serializable ( 
State makeState(Map conf, IMetricsContext metrics, int partitionIndex, int numPartitions); 


j 

这 个 接口 含有 一 个 makestate 方 法 ， 用 来 创建 一 个 新 的 State 对 象 ， 其 输入 参数 分 析 如 下 : 
O conf: 配置 项 。 

O metrics: 通常 会 传人 上 下 文 对 象 ， 例 如 TopologyContext 对 象 。 

口 partitionIndex: 当前 State 对 应 的 索引 。 

口 numPartitions: 表示 分 区 的 数目 。 

例如 ， 在 SubtopologyBolt 中 初始 化 存储 对 象 时 传人 的 参数 为 : 


State s = n.stateInfo.spec.stateFactory.makeState(conf, context, context.getThisTaskIndex(), this 
ComponentNumTasks) ; 
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conf: Topology 在 这 个 Component 上 面 的 配置 。 
metrics: X TopologyContextął % context, 
partitionIndex7j 3 3j Task&5Id, 
numPartitions 为 当前 Task 的 并 行 度 。 


StateSpec 类 中 包含 了 一 个 StateFactory 对 销 。requiredNumpartitions 将 在 TridentTopology 
类 中 进一步 讨论 ， 它 用 于 计算 subTopologyBolt 的 并 行 度 。 该 类 的 代码 如 下 : 
public class StateSpec implements Serializable { 


public StateFactory stateFactory; 
public Integer requiredNumPartitions - null; 


public StateSpec(StateFactory stateFactory) { 
this.stateFactory - stateFactory; 
) 


) 

用 户 需 要 实现 接口 IBackingMap 、 State、ValueUpdater 和 StateFactory 来 完成 自 定义 存储 的 
实现 ， 当 然 也 可 以 只 实现 其 中 的 一 个 部 分 来 增加 功能 。 

读者 可 以 参考 如 下 的 类 实现 来 学 习 如 何 实现 相应 的 接口 。 
口 State 接 口 : storm.trident.testing.MemoryMapState 
口 IBackingMap 接 口 : storm.trident.testing.MemoryMapState.MemoryMapStateBacking 


口 StateFactory 接 口 : storm.trident.testing.MemoryMapState.Factory 


Trident 消 息 


在 Trident 中 , 一 个 Bolt 节 点 中 可 能 含有 多 个 操作 (Operation ), 各 个 操作 之 间 需 要 进行 消息 传 
输 。 通 常 ， 操 作 或 者 产生 新 的 域 或 者 对 原来 的 域 进行 过 滤 ， 若 每 次 都 对 输入 的 消息 进行 复制 ， 则 
效率 不 高 。 

Trident 利 用 TridentTupleView 对 象 对 消息 进行 封装 。 例 如 ， 新 产生 的 消息 由 两 部 分 组 成 ， 一 
部 分 来 自 于 输入 ， 男 外 一 部 分 则 由 计算 得 到 。TridentTupleView 并 不 会 创建 一 个 新 的 消息 ， 而 是 
将 这 两 个 部 分 合并 , 通过 更 新 类 内 部 的 索引 使 得 从 外 部 看 来 如 同一 个 消息 一 样 。 这样 便 节省 了 消 
息 拷 贝 和 新 对 象 创建 等 方面 的 负担 ， 因 而 提高 了 效率 。 

TridentTupleView 是 Trident 中 使 用 的 消息 类 型 , 它 继承 自 AbstractList<0bject>, 同时 实现 了 
接口 TridentTuple。Trident 采 用 了 视图 的 方式 进行 了 优化 ， 不 需要 创建 新 的 消息 ， 而 只 是 更 新 索 
引 ， 并 且 索 引 在 构建 Bolt 对 象 时 就 已 经 创建 好 了 ， 这 些 都 进一步 地 提升 了 效率 。 

本 章 将 对 Trident 的 消息 及 其 构建 方法 进行 讨论 。 


19.1 ValuePointer 


ValuePointer 类 是 用 于 描述 TridentTupleView 中 索引 的 数据 结构 , 每 个 ValuePointer 对 和 象 对 应 
于 消息 的 一 个 域 , 它 保存 了 索引 用 以 访问 数据 ,同时 还 提供 了 一 些 工具 方法 帮助 完成 索引 的 构建 。 
该 类 的 定义 如 下 : 


public class ValuePointer { 
public static Map«String, ValuePointer» buildFieldIndex(ValuePointer[] pointers) ( 
Map«String, ValuePointer» ret - new HashMap«String, ValuePointer»(); 
for(ValuePointer ptr: pointers) { 
ret.put(ptr.field, ptr); 


return ret; 


} 


0 public static ValuePointer[] buildIndex(Fields fieldsOrder, Map<String, 
ValuePointer> pointers) { 


11 if(fieldsOrder.size()!-pointers.size()) { 
12 throw new IllegalArgumentException("Fields order must be same length as pointers map"); 
13 


14 ValuePointer[] ret = new ValuePointer[pointers.size()]; 
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15 List«String» flist = fieldsOrder.toList(); 

16 for(int i-0; i«fieldsOrder.size(); i++) { 

17 ret[i] = pointers.get(fieldsOrder.get(i)); 
18 

19 return ret; 

20 } 

21 

22 public int delegateIndex; 

23 protected int index; 

24 protected String field; 

25 

26 public ValuePointer(int delegateIndex, int index, String field) { 
27 this.delegateIndex = delegateIndex; 

28 this.index = index; 

29 this.field = field; 

30 } 

31 } 


a 第 22~24 行 定义 了 ValuepPointer 的 成 员 变量 。 

m delegateIndex 为 IJPersistentVector 类 型 的 索引 。TridentTupleview 中 可 能 含有 多 个 
IPersistentVector 对 象 ， 该 对 象 对 应 于 数据 存储 。 

m jndex 表 示 元 素 在 某 一 个 IPersistentVector 集 合 中 的 索引 。 

m field 表 示 列 的 名 称 。 

O 第 10~20 行 ，buildIndex 函 数 将 返回 一 个 ValuepPointer 类 型 的 对 象 数 组 。 用 户 可 以 根据 所 
在 列 的 下 标 来 访问 元 素 。fields0rder 表 示 输 入 列 的 顺序 ， 下 标 可 从 0 取 到 fieldsOrder. 
length-1。pointers 表 示 列 在 输入 消息 中 的 真正 索引 。 

O 第 2~8 行 ，buildFieldIndex 函 数 通 过 Valuepointer 数 组 返回 一 个 从 字段 名 指向 Valulepointer 
的 哈 希 表 。 

仔细 阅读 这 个 类 ， 明 白 其 中 成 员 变 量 以 及 这 两 个 工具 方法 的 含义 是 很 关键 的 。 


19.2 Factory 接口 及 其 实现 
Factory 接 口 用 来 描述 如 何 创建 Trident 消 息 ,本 节 将 分 析 该 接口 及 其 主要 实现 类 ,相关 代码 如 下 : 


public static interface Factory extends Serializable { 
Map«String, ValuePointer» getFieldIndex(); 
List<String> getOutputFields(); 
int numDelegates(); 


} 

O numDelegates 方 法 返回 实际 的 IPersistentVector 数 目 。 

口 getOutputFields 方 法 则 返回 从 外 部 看 到 的 消息 字段 名 ， 该 字段 名 可 能 是 由 底层 的 几 个 

IPersistentVector 的 字段 名 连接 组 合 而 成 的 。 

O getFieldIndex 方 法 将 返回 一 个 从 字段 名 到 ValulePointer 的 映射 关系 。ValulePointer 用 来 
访问 底层 数据 。 
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19.2.1 ProjectionFactory 


E: 

Fa 
P 
B 


该 


ProjectionFactory 根 据 输 入 的 parentFactory 以 及 需要 保留 的 字段 名 来 重新 构建 一 个 消息 。 注 
,ProjectionFactory 并 不 产生 新 的 消息 , 它 只 是 根据 输入 的 要 保留 的 字段 名 来 更 新 相应 的 索引 。 
工厂 类 主要 用 于 映射 操作 ， 其 代码 如 下 : 


1 public static class ProjectionFactory implements Factory { 

2 Map«String, ValuePointer> _fieldIndex; 

3 ValuePointer[] _index; 

4 Factory _parent; 

5 

6 public ProjectionFactory(Factory parent, Fields projectFields) { 

7 _parent = parent; 

8 if(projectFields==null) projectFields = new Fields(); 

9 Map«String, ValuePointer> parentFieldIndex = parent.getFieldIndex(); 

10 _fieldIndex = new HashMap<String, ValuePointer>(); 

11 for(String f: projectFields) { 

12 _fieldIndex.put(f, parentFieldIndex.get(f)); 

13 } 

14 _index = ValuePointer.buildIndex(projectFields, _fieldIndex) ; 

15. } 

16 

17 public TridentTuple create(TridentTuple parent) { 

18 if( index.length--0) return EMPTY TUPLE; 

19 else return new TridentTupleView(((TridentTupleView)parent). delegates, 
index, fieldIndex); 

20 } 

21 


22 @Override 

23 public Map<String, ValuePointer> getFieldIndex() { 
24 return _fieldIndex; 

25 } 

26 

27 @Override 

28 public int numDelegates() { 

29 return parent.numDelegates(); 

30 } 

31 

32 @Override 

33 public List<String> getOutputFields() { 
34 return indexToFieldsList(_index); 
35 ] 

36 } 


O 456-1517, 在 构造 函数 中 , 初始 化 _fieldsIndex 和 _index 成 员 变量 。 成员 变量 fieldsIndex 
中 包含 从 要 保留 的 字段 名 到 parent 中 的 字段 名 的 索引 。 然 后 ， 根 据 _fieldsIndex 以 及 
projectFields 来 构建 index 索 引 。 

O 第 17~20 行 ， 根 据 parent 的 数据 ， 以 及 通过 要 保留 的 列 重新 构建 的 _index 和 _fieldsIndex， 
返回 一 个 新 的 TridentTupleView 对 象 。 
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口 第 28~30 行 ，numDelegates 返 回 _parent 的 numDelegates。 这 也 表明 了 ProjectionFactory 并 
不 会 产生 新 的 列 。 


19.2.2 FreshOutputFactory 


FreshOutputFactory 根 据 输 入 的 字段 名 和 列 值 来 产生 一 个 新 消息 。 该 工厂 方法 对 应 于 产生 一 
条 新 消息 的 操作 ， 其 代码 如 下 : 


public static class FreshOutputFactory implements Factory { 
Map«String, ValuePointer»  fieldIndex; 
ValuePointer[] index; 


public FreshOutputFactory(Fields selfFields) { 
. fieldIndex = new HashMap«String, ValuePointer>(); 
for(int i-0; i«selfFields.size(); i++) { 
String field = selfFields.get(i); 
_fieldIndex.put(field, new ValuePointer(0, i, field)); 


} 
index = ValuePointer.buildIndex(selfFields, _fieldIndex) ; 


} 


public TridentTuple create(List<Object> selfVals) { 
return new TridentTupleView(PersistentVector.EMPTY.cons(selfVals), index, fieldIndex); 
) 


@Override 

public Map<String, ValuePointer> getFieldIndex() { 
return _fieldIndex; 

} 


@Override 

public int numDelegates() { 
return 1; 

} 


@Override 

public List<String> getOutputFields() { 
return indexToFieldsList(_index); 

} 


} 

可 以 看 出 ,该 类 的 numDelegates 方 法 返回 值 为 1, 其 create 方 法 需要 传人 构成 TridentTupleView 
的 值 列 表 。 _index 和 fieldsIndex 变 量 则 由 输入 的 字段 名 构建 而 来 。 
19.2.3 OperationOutputFactory 


0peration0utputFactory 将 输入 的 消息 与 产生 的 消息 连接 以 生成 新 的 消息 。 顾 名 思 义 ， 这 个 
类 主要 用 于 添加 新 域 ， 其 代码 如 下 : 
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1 public static class OperationOutputFactory implements Factory ( 

2 Map«String, ValuePointer» _fieldIndex; 

3 ValuePointer[] index; 

4 Factory parent; 

5 

6 public OperationOutputFactory(Factory parent, Fields selfFields) ( 

7 parent - parent; 

8 _fieldIndex = new HashMap(parent.getFieldIndex()); 

9 int myIndex = parent.numDelegates(); 

10 for(int i-0; i«selfFields.size(); i++) { 

11 String field = selfFields.get(i); 

12 _fieldIndex.put(field, new ValuePointer(myIndex, i, field)); 

13 } 

14 List<String> myOrder = new Arraylist«String»(parent.getOutputFields()); 
15 

16 Set<String> parentFieldsSet = new HashSet<String>(myOrder) ; 

17 for(String f: selfFields) { 

18 if(parentFieldsSet.contains(f)) { 

19 throw new IllegalArgumentException( 

20 "Additive operations cannot add fields with same name as already exists. " 
21 + "Tried adding " + selfFields + " to " + parent.getOutputFields()); 
22 

23 myOrder.add(f); 

24 } 

25 

26 index = ValuePointer.buildIndex(new Fields(myOrder),  fieldIndex); 

27 ] 

28 

29 public TridentTuple create(TridentTupleView parent, List«Object» selfVals) ( 
30 IPersistentVector curr - parent. delegates; 

31 curr - (IPersistentVector) RT.conj(curr, selfVals); 

32 return new TridentTupleView(curr, index, _fieldIndex); 

3 } 

34 


35 GOverride 

36 public Map«String, ValuePointer» getFieldIndex() ( 
37 return fieldIndex; 

38 } 


40 @Override 

41 public int numDelegates() ( 

42 return parent.numDelegates() + 1; 
43 } 


45 @Override 

46 public List<String> getOutputFields() { 
47 return indexToFieldslist( index); 
48 } 

49 } 


a 第 6~27 行 的 构造 函数 以 parent 为 输入 的 工厂 ，selfFields 表 示 将 要 产生 的 字段 名 , 最终 产 
生 的 消息 将 包含 所 有 输入 工厂 中 的 列 以 及 selfFilds 中 要 包含 的 列 。 
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O 第 8 行 获得 父 工厂 的 fieldsIndex 索 引 。 


口 第 9 行 , selfFields 中 的 列 将 被 放 入 一 个 新 的 delegate 存 储 中 ,所 以 它 将 parent.numDelega tes 


作为 自己 的 delegateIndex。 注 意 ，delegate 的 索引 是 从 0 开始 的 。 然 后 在 第 41~43 行 中 ，num 
Delegates 将 在 原来 parent.numDelegates 的 基础 上 加 1。 


字段 名 发 生 冲 突 。 


19.2.4 RootFactory 


口 第 10~13 行 将 selfFields 中 的 列 加 入 到 fieldsIndex 中 。 
a 第 16~24 行 构建 用 于 输出 的 字段 名 列表 ， 这 里 不 允许 selfFields 中 的 字段 名 与 parent 中 的 


RootFactory 为 操作 的 入 口 工 厂 ， 对 输入 的 消息 起 到 适 配 作 用 。 它 会 根据 输入 消息 产生 一 个 


TridentTupleView 类 型 的 消息 ， 这 个 产生 的 消 


息 可 以 被 其 他 工厂 方法 使 用 。 对 象 Tuple 是 在 Storm 


中 传输 的 对 象 。 这 里 不 再 详细 分 析 这 个 类 的 代码 ， 仅 列 于 此 处 以 供 参考 : 


public static class RootFactory implements Factory { 


ValuePointer[] index; 
Map«String, ValuePointer» fieldIndex; 


public RootFactory(Fields inputFields) ( 
index - new ValuePointer[inputFields 
int i=0; 
for(String f: inputFields) ( 


.size()]; 


index[i] = new ValuePointer(0, i, f); 


i++; 


fieldIndex = ValuePointer.buildFieldIndex(index) ; 


} 


public TridentTuple create(Tuple parent) 


{ 


return new TridentTupleView(PersistentVector.EMPTY.cons(parent.getValues()), index, 


fieldIndex); 
) 


@Override 


public Map<String, ValuePointer> getFieldIndex() { 


return fieldIndex; 


} 


@Override 

public int numDelegates() { 
return 1; 

} 


@Override 
public List<String> getOutputFields() { 


return indexToFieldsList(this. index) ; 


} 
} 
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19.3 ”消息 工厂 的 例子 


假定 输入 的 消息 含有 列 (A, B, C, D)， 并 依次 进行 一 系列 消息 工厂 方法 的 操作 。 具 体 的 操作 与 
结果 如 表 19-1 所 示 。 其 中 (1, 0, A) 用 来 表示 一 个 ValuePointer 对 象 ， 意义 为 存储 1 的 第 1 列 的 字段 名 
FRA. 


表 19-1 工厂 操作 示例 


Factory Num-Delegates fieldsIndex index 描 述 

RootFactory 1 A->(0, 0,A) 0->(0, 0,A) 输入 消息 
B->(0, 1, B) 1->(0, 1, B) 
C->(0, 2, C) 2->(0, 2, C) 
D->(0, 3, D) 3->(0, 3, D) 

ProjectionFactory 1 A->(0, 0, A) 0->(0, 0, A) 取 A，C 列 
C->(0, 2, C) 1->(0, 2, C) 

OperationOutputFactory 2 A->(0, 0, A) 0->(0, 0, A) 增加 E，F 列 
C->(0, 2, C) 1->(0, 2, C) 
E->(1, 0, E) 2->(1, 0, E) 
F->(1, 1, F) 3->(1, 1, F) 

ProjectionFactory 2 A->(0, 0, A) 0->(0, 0, A) 保留 A，F 列 
F->(1, 1, F) 1->(1, 1, F) 

FreshOutputFactory 1 G->(0, 0, G) 0->(0, 0, G) 产生 G 列 


19.4 TridentTupleView 


Mr 


基于 前 面 的 讨论 ， 我 们 接 下 来 看 类 TridentTupleVview。 这 个 类 实现 了 TridentTuple 接 口 ， 该 
接口 提供 了 很 多 可 将 输出 的 列 值 转化 成 目标 类 型 的 工具 方法 。 同 时 ， 这 个 类 还 扩展 了 
AbstractList 类 ， 这 使 得 TridentTupleView 消 息 可 直接 以 Storm 消 息 的 形式 被 发 送出 去 。 该 类 的 代 
人 码 如 下 : 


1 //extends abstractlist so that it can be emitted directly as Storm tuples 
2 public class TridentTupleView extends AbstractList<Object> implements TridentTuple { 
3 ValuePointer[] index; 


4 Map«String, ValuePointer» _fieldIndex; 

5 IPersistentVector delegates; 

6 

7 public static TridentTupleView EMPTY TUPLE - new TridentTupleView(null, new 
ValuePointer[0], new HashMap()); 

8 

9 // index and fieldIndex are precomputed, delegates built up over many operations 


using persistent data structures 

10 public TridentTupleView(IPersistentVector delegates, ValuePointer[] index, 
Map«String, ValuePointer» fieldIndex) { 

11 delegates - delegates; 

12 index - index; 

13  fieldIndex - fieldIndex; 
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14 jJ 


16 @Override 

17 public Object get(int i) { 
18 return getValue(i); 

19 ] 


21 @Override 

22 public Object getValue(int i) { 

23 return getValueByPointer(_index[i]); 
24 ] 


26 @Override 

27 public Object getValueByField(String field) { 

28 return getValueByPointer( fieldIndex.get(field)); 
29 } 


31 private Object getValueByPointer(ValuePointer ptr) { 
32 return ((List«Object») delegates.nth(ptr.delegateIndex)).get(ptr.index); 
33  ] 


O 第 17~19 行 代码 覆盖 AbstractList 的 get 方 法 ， 它 将 调用 getvalue 方 法 ， 这 是 可 以 把 
TridentTupleView 作 为 消息 进行 发 送 的 基础 。 

口 第 31~33 行 代码 根据 输入 的 ValulePointer 对 象 获得 数据 。 首先 根据 ptr.delegateIndex 获 得 
delegate 引 用 ， 然 后 根据 ptr.index 获 取 前 面 delegate 引 用 上 的 第 ptr.index 个 元 素 。 

口 第 27~29 行 代码 根据 输入 的 字段 名 field 以 及 _fieldIndex 映 射 关系 找到 其 所 对 应 的 
ValuePointer， 并 调用 getValueByPointer 方 法 。 

口 第 22~24 行 代码 根据 输入 列 的 下 标 i 以 及 _index 找 到 与 第 i 列 相 对 应 的 索引 ， 然 后 调用 
getValueByPointer 方 法 获得 列 值 。 这 样 ，TridentTupleView 便 既 支 持 以 字段 名 的 方式 访问 
元 素 也 支持 通过 下 标的 方式 访问 元 素 了 。 


19.5 ComboList 


ComboList 的 设计 与 TridentTupleview 非 常 相似 ， 它 将 输入 的 列表 进行 连接 并 创建 索引 。 
TridentTupleView 主 要 用 于 各 个 操作 之 间 的 消息 传输 ， 而 ComboList 仅 为 Trident 中 的 工具 方法 。 


public class ComboList extends AbstractList<Object> { 
public static class Factory implements Serializable { 
Pointer[] index; 
int[] sizes; 


this.sizes - sizes; 

int total - 0; 

for(int size: sizes) { 
total+=size; 


o 


1 
2 
3 
4 
5 
6 public Factory(int... sizes) { 
7 
8 
9 
1 
1 


1 } 
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12 index = new Pointer[total]; 

13 int i-0; 

14 int j-0; 

15 for(int size: sizes) { 

16 for(int z=0; z<size; z++) { 

17 index[j] = new Pointer(i, z); 

18 j+; 

19 } 

20 i++; 

21 } 

22 } 

23 

24 public ComboList create(List[] delegates) { 

25 if(delegates.length!=sizes.length) { 

26 throw new RuntimeException("Expected " + sizes.length + " lists, but instead got " 
+ delegates.length + " lists"); 

27 } 

28 for(int i=0; i<delegates.length; i++) { 

29 List 1 = delegates[i]; 

30 if(l--null || 1.size() != sizes[i]) ( 

31 throw new RuntimeException("Got unexpected delegates to Combolist: " + 

ToStringBuilder.reflectionToString(delegates)); 

32 } 

33 } 

34 return new ComboList(delegates, index); 

35 } 

36 } 

37 

38 private static class Pointer implements Serializable { 

39 int listIndex; 

40 int subIndex; 

41 

42 public Pointer(int listIndex, int subIndex) ( 

43 this.listIndex - listIndex; 

44 this.subIndex = subIndex; 

45 } 

46 

47 } 

48 

49 Pointer[] _index; 

50 List[] _delegates; 

51 

52 public ComboList(List[] delegates, Pointer[] index) { 

53 _index = index; 

54 _delegates = delegates; 

55 } 

56 

57 GOverride 

58 public Object get(int i) { 

59 Pointer ptr - index[i]; 

60 return delegates[ptr.listIndex].get(ptr.subIndex); 

61 } 

62 


63 @Override 
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64 public int size() ( 

65 return index.length; 
66 } 

67 } 


O 第 38~47 行 代码 定义 私有 类 Pointer 对 象 。listIndex 为 第 一 层 索 引 ， 表示 所 在 的 列表 索引 ; 
subIndex 为 第 二 层 索 引 ， 表 示 在 某 一 个 列表 内 部 的 索引 。 

a 第 2~22 行 代码 定义 了 内 部 类 Factory。Index 是 Pointer 的 对 象 ， 用 来 访问 列表 中 的 元 素 ; 
sizes 成 员 变量 用 来 表示 每 一 个 列表 的 列 数 。 该 类 主要 用 于 对 输入 进行 有 效 性 验证 。 

口 第 6~22 行 代码 ， 在 Factory 的 构造 函数 中 ， 利 用 输入 的 每 个 列表 的 列 数目 构建 索引 。 

口 第 58~61 行 代码 实现 了 ComoList 的 get 方 法 ， 它 会 根据 输入 列 的 下 标 找到 Pointer 对 象 ， 再 
根据 Pointer 对 象 访问 具体 的 元 素 。 

口 与 TridentTupleView 相 比 ，ComboList 更 加 灵活 , 它 可 以 接收 多 个 列表 作为 输入 , 使 它们 从 
外 界 看 来 就 如 同一 个 列表 。 同 时 ，ComobList 继 承 自 AbstractList， 所 以 也 可 以 作为 Storm 
的 消息 进行 发 送 。 


Trident 操 作 与 处 理 节点 


Trident 中 定义 了 较 多 的 操作 接口 ， 用 户 通 常 需要 实现 这 些 接口 来 具体 地 使 用 它们 , 详情 可 参 
JLhttps://github.com/nathanmarz/storm/wiki/Trident-API-Overview. 

流 是 Trident 数 据 模型 中 的 核心 概念 ， 一 个 流 经 过 分 区 操作 ， 会 分 布 在 集群 中 的 不 同 节 点 上 。 
这 些 针 对 同一 个 流 的 操作 可 以 在 集群 中 并 行 起 来 。 根 据 具 体 方式 的 不 同 ， 目 前 有 5 种 类 型 的 流 操 
作 ， 如 表 20-1 所 示 。 


表 20-1 流 操作 类 型 


类 型 描 Ë 
局 部 操作 (Local Operation) 应 用 于 一 个 分 区 内 部 ， 不 会 产生 网 络 传输 ， 通 常 被 放置 于 Bolt 节 点 中 执行 
分 区 操作 (Repartition Operation) 对 一 个 流 进 行 重新 分 区 ， 但 并 不 改变 内 容 ， 会 导致 网 络 传输 
聚集 操作 (Aggregation Operation) 对 分 区 中 数据 进行 聚集 ， 会 产生 网 络 传输 
分 组 操作 (Grouped Operation) 在 分 组 流 (Grouped Stream) 上 进行 的 操作 
合并 连接 操作 (Merge & Join) 流 之 间 合 并 以 及 连接 


本 章 及 接 下 来 的 两 章 将 介绍 Trident 的 操作 接口 以 及 对 流 的 操作 。 本 章 主 要 介绍 聚集 器 接口 、 
Trident 中 的 处 理 节点 ， 以 及 如 何在 Trident 中 执行 聚集 器 类 型 的 操作 。 


20.1 操作 的 基本 接口 


0peration 接 口 为 Trident 中 的 操作 接口 ， 而 Filter 、Function 和 Aggregator 接 口 则 是 用 户 实 际 
使 用 的 接口 。 操 作 接 口 的 类 关系 如 图 20-1 所 示 ， 它 们 的 基本 含义 见 表 20-2。 
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t Operation 


@ prepare(Map,TridentOpentOperationContext) void 
&® deanup() void 


EE NEN: 


Aggergator 
€ BaseOperation A Ad 


z jinit(Object,TridentCollect E 
t EachOperation | @ prepare(Map,TridentOperationContext) void ibn e oe e er M ctor) 
| | @ deanup() void a) complete(T, TridentCollector) void 
®) Filter, t Function 
@isKeep(TridentTuple) boolean wexecute(TridentTuple,TridentCollector) void 
p p. p. 
ANN 
€ BaseFunction 


图 20-1 ”操作 接口 的 关系 


表 20-2 ”操作 接口 描述 

接 oOo ”主要 方法 Hoo 

Operation prepare 对 Trident 操 作 的 抽象 
cleanup TridentOperationContext 含 有 该 组 件 的 输入 信息 以 及 Topology 的 上 下 文 信息 
EachOperation 无 新 方法 对 每 条 数据 均 进 行 处 理 的 抽象 
Filter iskeep 对 于 输入 的 消息 ， 调 用 iskeep 方 法 判断 是 否 输出 或 丢掉 
Function execute 一 个 函数 对 输入 的 消息 进行 处 理 , 可 以 有 一 条 或 者 多 条 消息 输出 , 新 产生 出 来 的 列 被 
放 在 原 有 列 的 后 面 ， 即 Function 不 会 使 列 数 减少 


BaseOperation 无 新 方法 


Aggregator init 聚集 操作 的 抽象 。Batch 开 始 时 调用 init 方 法 ,聚集 过 程 中 调用 aggregate 方 法 ， 聚 集结 
aggregate 束 时 调用 complete 方 法 
complete 


20.2 Aggregator 实现 
Aggregator 接 口 是 关于 聚集 操作 的 核心 接口 ， 其 实现 是 本 章 的 重点 ， 关 于 Aggregator 的 主要 
实现 类 关系 如 图 20-2 所 示 。 


E Operation 


| 


I Aggregator 


1 
1 1 1 1 1 
1 1 


I 1 1 
c SingleEmitAggregator € ConbinerAggregatorConbineInpl | © GroupedAggregator | 5 ChainedAggregatorImpl| c ReducerAggregatorImpl 


图 20-2 ”聚集 接口 的 实现 类 关系 
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本 节 将 分 别 讨论 这 些 聚 集 怖 的 实现 以 及 主要 用 途 。 
20.2.1 GroupedAggregator 


流 的 分 组 操作 ( Group By ) 即 对 流 中 的 数据 按照 某 些 域 进行 分 组 。 在 具体 的 某 个 分 组 上 ， 可 
以 使 用 GroupedAggregator 类 对 该 分 组 中 的 消息 进行 聚集 操作 。 该 类 的 定义 如 下 所 示 : 


1 public class GroupedAggregator implements Aggregator«Object[]» { 
2 ProjectionFactory groupFactory; 

3 ProjectionFactory _inputFactory; 

4 Aggregator agg; 

5 Combolist.Factory fact; 

6 Fields inFields; 

7 Fields groupFields; 

8 
9 


public GroupedAggregator(Aggregator agg, Fields group, Fields input, int outSize) { 


10  groupFields - group; 

11  inFields - input; 

12 _a88 = agg; 

13 int[] sizes = new int[2]; 

14 sizes[0] = _groupFields.size(); 

15 sizes[1] = outSize; 

16 _fact = new ComboList.Factory(sizes); 
17 } 

18 


19 @Override 
20 public void prepare(Map conf, TridentOperationContext context) { 


21 _inputFactory = context.makeProjectionFactory( inFields); 

22  groupFactory - context.makeProjectionFactory( groupFields); 

23  agg.prepare(conf, new TridentOperationContext(context,  inputFactory)); 
24 

25 


26 @Override 

27 public Object[] init(Object batchId, TridentCollector collector) { 

28 return new Object[] {new GroupCollector(collector, fact), new HashMap(), batchId}; 
29 ] 


31 @Override 
32 public void aggregate(Object[] arr, TridentTuple tuple, TridentCollector collector) { 


33 GroupCollector groupColl = (GroupCollector) arr[0]; 

34 Map«List, Object» val = (Map) arr[1]; 

35 TridentTuple group = groupFactory.create((TridentTupleView) tuple); 
36 TridentTuple input = _inputFactory.create((TridentTupleView) tuple); 
37 Object curr; 

38 if(!val.containsKey(group)) { 

39 curr = agg.init(arr[2], groupColl); 

40 val.put((List) group, curr); 

41 ) else ( 

42 curr = val.get(group); 

43 } 

44 groupColl.currGroup = group; 


45 _agg.aggregate(curr, input, groupColl); 
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47 } 


49 @Override 
50 public void complete(Object[] arr, TridentCollector collector) { 


51 Map«List, Object» val = (Map) arr[1]; 

52 GroupCollector groupColl = (GroupCollector) arr[0]; 
53 for(Entry<List, Object» e: val.entrySet()) { 

54 groupColl.currGroup - e.getKey(); 

55  agg.complete(e.getValue(), groupColl); 

56 

57 ] 

58 


59 @Override 

60 public void cleanup() { 
61 _agg.cleanup(); 

62 } 


O 第 1 行 ，GroupedAggregator 实 现 了 Aggegator 接 口 ， 聚 集 的 结果 被 放 在 一 个 对 象 数组 中 。 从 
第 27~29 行 定义 的 init 方 法 可 以 看 出 ， 该 对 象 数组 含有 3 个 元 素 。 
m GroupCollector: 实现 TridentCollector 接 口 。 其 消息 由 两 部 分 组 成 ， 分 别 为 用 于 分 组 
的 列 和 用 于 存储 聚集 结果 的 列 。 
m 哈 希 表 对 象 : 用 来 存储 聚集 结果 ， 键 为 分 组 的 列 值 ， 值 为 聚集 结 
事务 序号 : 事务 的 序号 标识 符 。 
口 类 的 成 员 变 量 分 析 如 下 。 
m groupedFactory: 根据 分 组 的 列 获得 的 相应 的 列 值 。 
m inputFactory: 根据 需要 的 输入 列 获得 的 相应 的 列 值 。 
m agg: 内 谱 的 Aggregator， 用 于 对 属于 同一 个 分 组 的 消息 进行 聚集 。 
m fact: 用 于 描述 输出 ， 它 由 两 个 部 分 构成 ， 即 分 组 的 列 和 新 产生 的 列 。 
m inputFields: 输入 的 字段 名 。 
m groupFields: 用 于 分 组 的 字段 名 。 
O 第 32~47 行 实现 了 核心 的 aggregate 方 法 。 第 35~36 行 利用 工厂 方法 获得 输入 消息 和 进行 分 
组 的 消息 C group 为 消息 input 的 某 些 列 ), 第 37~43 行 以 分 组 消息 为 键 获 得 当前 分 组 上 的 聚 
集 值 , 若 目 前 还 没有 聚集 值 , 则 调用 _agg 的 init 方 法 进行 初始 化 ,表示 第 一 次 遇 到 某 个 分 
组 中 的 元 素 。 
口 第 45 行 调用 _agg 的 aggregate 方 法 ， 传 和 人 的 参数 为 当前 消息 和 当前 分 组 的 聚集 值 。 
O 第 50~57 行 实现 了 complete 方 法 ， 这 表示 属于 某 一 个 事务 的 处 理 结束 ， 也 意味 着 在 这 个 分 
组 上 面 的 聚集 已 经 完成 。 
口 第 51 行 的 val 变 量 包含 了 以 分 组 值 作为 键 的 结果 。 第 55 行 依次 在 每 个 分 组 上 调用 _agg 的 
complete 方 法 。 
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20.2.2  ChainedAggregatorImpl 
ChainedAggregatorImp1 类 中 可 以 含有 多 个 聚集 器 ， 它 会 依次 调用 这 些 聚 集 器 ,并 在 最 后 通 ; 


SAA (Cross Join ) 的 方式 将 各 个 聚集 器 的 聚集 结果 发 送出 去 。 
ChainedResult 类 用 来 存储 聚集 的 结果 ， 其 定义 如 下 : 


Et 


public class ChainedResult { 
Object[] objs; 
TridentCollector[] collectors; 


public ChainedResult(TridentCollector collector, int size) { 
objs = new Object[size]; 
collectors = new TridentCollector[size]; 
for(int i-0; i«size; i++) { 
if(size--1) ( 
collectors[i] = collector; 
} else { 
collectors[i] = new CaptureCollector(); 
} 


} 

} 

ChainedResult 类 包含 两 个 成 员 变量 ，objs 用 来 存储 聚集 过 程 的 中 间 结 果 ，collectors 被 聚集 
器 用 来 发 送 结果 。 从 它 的 构造 函数 可 以 看 出 ， 如 果 要 使 用 多 个 聚集 器 时 ，collector 将 被 初始 化 
为 CaptureCollector。 

ChainedAggregatorImp1 类 包含 了 一 组 聚集 咒 , 对 于 输入 的 消息 , 该 类 将 依次 调用 这 些 聚 集 带 ， 
并 在 最 后 将 每 一 个 聚集 右 的 结果 通过 又 积 的 方式 发 送出 去 。 下 面 我 们 来 分 析 一 下 ChainedAggrega 
torImpl 的 实现 ， 其 代码 如 下 : 


nr 


1 public class ChainedAggregatorImpl implements Aggregator«ChainedResult» { 
2 Aggregator[] _aggs; 

3 ProjectionFactory[] _inputFactories; 

4 ComboList.Factory fact; 

5 Fields[] inputFields; 
6 
7 
8 
9 


public ChainedAggregatorImpl(Aggregator[] aggs, Fields[] inputFields,ComboList.Factory fact) { 


—8885 = ages; 
10 _inputFields = inputFields; 
11 fact - fact; 
12 if( aggs.length!- inputFields.length) { 
13 throw new IllegalArgumentException("Require input fields for each aggregator"); 
14 } 
15 } 
16 
17 public void prepare(Map conf, TridentOperationContext context) { 
18 _inputFactories = new ProjectionFactory[ inputFields.length]; 


19 for(int i20; i« inputFields.length; i++) { 
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20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 
45 
46 
47 
48 
49 
50 
51 
52 
53 
54 
55 
56 
57 
58 
59 
60 
61 
62 
63 
64 
65 
66 
67 
68 
69 
70 
71 
72 
73 


_inputFactories[i] = context.makeProjectionFactory( inputFields[i]); 
 aggs[i].prepare(conf, new TridentOperationContext(context, inputFactories[i])); 


} 


public ChainedResult init(Object batchId, TridentCollector collector) { 
ChainedResult initted = new ChainedResult(collector, _aggs.length); 
for(int i-0; i« aggs.length; i++) { 
initted.objs[i] = _aggs[i].init(batchId, initted.collectors[i]); 
} 


return initted; 


} 


public void aggregate(ChainedResult val, TridentTuple tuple, TridentCollector collector) { 
val.setFollowThroughCollector(collector) ; 
for(int i=0; i<_aggs.length; i++) { 
TridentTuple projected = _inputFactories[i].create((TridentTupleView) tuple); 
_aggs[i].aggregate(val.objs[i], projected, val.collectors[i]); 


} 


public void complete(ChainedResult val, TridentCollector collector) { 
val.setFollowThroughCollector(collector) ; 
for(int i=0; i<_aggs.length; i++) { 
_aggs[i].complete(val.objs[i], val.collectors[i]); 


if(_aggs.length > 1) { // otherwise, tuples were emitted directly 
int[] indices = new int[val.collectors.length]; 
for(int i=0; i«indices.length; i++) { 
indices[i] = 0; 
} 


boolean keepGoing = true; 
//emit cross-join of all emitted tuples 
while(keepGoing) { 
List[] combined = new List[_aggs. length]; 
for(int i-0; i« _aggs.length; i++) { 
CaptureCollector capturer = (CaptureCollector) val.collectors[i]; 
combined[i] = capturer.captured.get(indices[i]); 


collector.emit( fact.create(combined)); 
keepGoing - increment(val.collectors, indices, indices.length - 1); 


} 


//return false if can't increment anymore 
private boolean increment(TridentCollector[] lengths, int[] indices, int j) { 
if(j==-1) return false; 
indices[j]++; 
CaptureCollector capturer = (CaptureCollector) lengths[j]; 
if(indices[j] >= capturer.captured.size()) { 
indices[j] = 0; 
return increment(lengths, indices, j-1); 
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74 return true; 

75 ] 

76 

77 public void cleanup() { 

78 for(Aggregator a: aggs) { 
79 a.cleanup(); 

80 } 

8 } 


口 _aggs 为 ChainedAggregatorImpl 中 包含 的 聚集 器 链 。 

口 _inputFields 为 每 一 个 聚集 器 所 对 应 的 输入 。 

O _ inputFactories 为 负责 根据 inputFields 来 产生 消息 的 工矿， 其 个 数 应 与 inputFields 和 

_aggs 的 个 数 相同 。 

口 _fact 用 来 存储 最 终结 果 ， 它 是 所 有 聚集 器 结果 的 合并 。 

口 当 aggs 仅 含有 一 个 Aggregator 时 ，ChainedAggregatorImp1 将 退化 为 普通 的 聚集 需 。 

O 第 8~15 行 定义 了 构造 函数 ， 其 中 需要 为 每 一 个 聚集 器 指定 一 个 输入 的 字段 名 。 

O 第 17~23 行 ,在 prepare 方 法 中 ,根据 聚集 器 输入 的 Fields 定 义 一 个 工厂 ,该 工厂 可 根据 Fields 
将 输入 的 原始 消息 转换 成 聚集 器 输入 所 需 的 消息 类 型 ， 主 要 是 对 输入 列 进行 过 滤 以 及 将 
字段 名 重新 排列 等 。 最 后 调用 聚集 希 自 身 的 prepare 方 法 。 

口 第 25~31 行 是 init 方 法 的 实现 。 这 里 将 调用 每 一 个 聚集 器 的 init 方 法 ， 并 将 结果 存储 于 

ChainedResult 中 的 objs 对 象 中 ， 它 是 聚集 过 程 的 中 间 结 果 。 

口 第 33~39 行 为 aggregate 方 法 的 具体 实现 。 这 里 将 对 输入 的 消息 逐一 调用 聚集 器 的 

aggregate 方 法 。 

O 第 41~63 行 代码 实现 complete 方 法 。 其 复杂 性 在 于 ， 者 存在 多 个 聚集 器 时 ， 将 输出 所 有 结 
果 的 又 积 作为 最 终 的 结果 。 例 如 : 

Aggri: A1, A2 

Aggr2: B1, B2 

Aggr3: C1 

其 中 Al 、A2 表 示 为 Aggrl 的 两 个 输出 结果 。 

那么 ， 最 终 的 结果 将 含有 4 个 消息 ， 并 且 每 个 消息 包含 三 列 ， 依 次 为 : 
M1, B1, C1 

A1, B2, C1 

A2, B1, C1 

A2, B2, C1 

O 第 47~48 行 代码 定义 了 indices 数 组 并 初始 化 为 0， 用 来 表示 每 个 聚集 器 结果 的 下 标 。 第 

54~59 行 代码 根据 indices 中 的 数值 取出 元 素 并 发 送出 去 。 

口 第 66~75 行 代码 调整 了 indices 中 的 下 标 位 置 ， 其 基本 思想 是 ， 如 果 最 后 一 个 聚集 器 的 下 
标 已 经 超过 了 其 元 素 个 数 ， 则 开始 调整 前 一 个 聚集 器 的 下 标 。 不 过 在 代码 的 第 60 行 ， 始 
终 都 是 传人 聚集 器 数目 少 1 作为 下 标 调整 的 初始 值 ， 这 保证 了 最 终结 果 是 所 有 聚集 器 结 
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的 义 积 (Cross Join )。 该 算法 较为 精巧 ， 由 于 所 包含 的 聚集 器 的 数目 并 不 确定 ， 多 重 循环 
算法 在 这 里 是 不 合适 的 。 


20.2.3 SingleEmitAggregator 


SingleEmitAggregator 类 用 于 应 对 聚集 集合 为 空 的 情况 。 此 时 只 需要 其 中 的 一 个 节点 向 目标 
节点 发 送 消 息 ， 且 该 消息 含有 聚合 结果 的 初始 值 即 可 。 ai P 
Aggregator 类 中 定义 的 ， 下 面 来 看 该 接口 的 定义 及 其 两 个 实现 。 


public static interface BatchToPartition extends Serializable { 
int partitionIndex(Object batchId, int numPartitions); 
} 


BatchToPartition 接 口中 的 方法 partitionIndex， 可 根据 batchId 以 及 分 区 数目 获得 当前 可 以 
发 送 消息 的 分 区 ID。 目 前 numPartitions 为 Task 的 索引 ,表示 通过 该 节点 可 以 向 目标 节点 发 送 消息 。 
Trident 中 有 两 个 实现 了 该 接口 的 类 。 

GlobalBatchTopPartition 类 始终 使 用 第 一 个 节点 来 发 送 消 息 ， 其 定义 如 下 : 


public class GlobalBatchToPartition implements SingleEmitAggregator.BatchToPartition { 
public int partitionIndex(Object batchId, int numPartitions) ( 
// TODO: take away knowledge of storm's internals here 
return 0; 


} 


而 IndexHashBatchTopartition 类 则 利用 事务 序号 的 哈 希 值 来 计算 由 哪个 节点 发 送 该 消息 , 其 
定义 如 下 : 


public class IndexHashBatchToPartition implements 
SingleEmitAggregator.BatchToPartition ( 
public int partitionIndex(Object batchId, int numPartitions) ( 
return IndexHashGrouping.objectToIndex(batchId, numPartitions); 
} 


we 


最 后 ， 来 看 SingleEmitAggregator 的 实现 ， 其 代码 如 下 : 


1 public class SingleEmitAggregator implements Aggregator<SingleEmitState> { 
2 static class SingleEmitState { 

3 boolean received = false; 

4 Object state; 

5 Object batchId; 

6 public SingleEmitState(Object batchId) { 

7 this.batchId = batchId; 

8 } 

9 } 

10 


11 Aggregator agg; 
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12 BatchToPartition batchToPartition; 

13 

14 public SingleEmitAggregator(Aggregator agg, BatchToPartition batchToPartition) { 

15 _agg = agg; 

16  batchToPartition - batchToPartition; 

17 } 

18 

19 @Override 

20 public SingleEmitState init(Object batchId, TridentCollector collector) { 

21 return new SingleEmitState(batchId); 

22 } 

23 

24 @Override 

25 public void aggregate(SingleEmitState val, TridentTuple tuple, TridentCollector collector) { 

26 if(!val.received) { 

27 val.state = _agg.init(val.batchId, collector); 

28 val.received = true; 

29 } 

30 _agg.aggregate(val.state, tuple, collector); 

31 

32 

33 @Override 

34 public void complete(SingleEmitState val, TridentCollector collector) { 

35 if(!val.received) { 

36 if(this.myPartitionIndex == batchToPartition.partitionIndex(val.batchId, this. 
totalz Partitions)) { 

37 val.state = _agg.init(val.batchId, collector); 

38 _agg.complete(val.state, collector); 

39 

40 ) else ( 

41 _agg.complete(val.state, collector); 

42 } 

43 } 

44 

45 int myPartitionIndex; 

46 int totalPartitions; 

47 

48 @Override 

49 public void prepare(Map conf, TridentOperationContext context) { 

50 _agg.prepare(conf, context); 

51 this.myPartitionIndex = context.getPartitionIndex(); 

52 this.totalPartitions = context.numPartitions(); 

53 j 

54 } 


口 SingletmitStateJSingletmitAggregator/t( THEE RUZIGSAS I, Jtr, received XR 
的 集合 是 否 含有 数据 ，batchId 表 示 事 务 序号 ，state 为 实际 的 聚集 结果 对 象 。 

口 myPartitionIndex 为 当前 Task 的 索引 ，totalPartitions 为 Task 的 并 行 度 。 

O 第 24~31 行 的 aggregate 方 法 被 调用 时 , 表明 该 集合 是 有 数据 的 , 这 里 会 设置 received 为 true。 
O 第 27 行 调用 _agg 的 init 方 法 ， 此 处 为 第 一 次 收 到 该 集合 中 的 数据 。 

O 第 34~43 行 的 complete 方 法 实现 中 ， 若 received 为 false， 表 明 集 合 为 空 ， 则 判断 是 否 由 当 


HB 
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前 的 节点 来 发 送 集合 初始 化 得 到 消息 。Complete 方 法 会 调用 partitionIndex 方 法 来 获得 应 
由 哪个 节点 发 送 该 消息 。 


( 即便 是 初始 化 消 


口 第 37~38 行 调用 _agg 的 init 方 法 以 及 complete 方 法 。 
O 在 Trident 中 , 有 时 候 上 游 的 聚集 节点 没有 产生 聚集 结果 , 但 下 游 节点 仍然 需要 其 发 送 消息 
E) 来 完成 操作 ( 例如 ， 连 接 操作 等 )。 


20.8 用户 接 口 及 其 实现 


聚集 器 接口 是 Trident 的 基本 接口 ,但 它们 并 不 能 满足 所 有 的 需求 。 因 此 ,Trident 定 义 了 Reducer 
Aggregator 和 CombinerAggregator 两 个 新 的 接口 ， 用 以 丰富 聚集 操作 的 类 型 。 由 于 这 两 种 接口 都 


不 是 继承 自 Aggregator 接 


口 的 ，Trident 采 用 了 与 前 面 介绍 内 容 相 类 似 的 技术 ， 通 过 分 别 实现 它们 


的 执行 类 来 完成 接口 的 适 配 。 


20.3.1 ReducerAggregator 接 口 及 其 实现 


ReducerAggregator 接 口 是 对 聚集 操作 的 一 种 抽象 ， 这 个 抽象 更 加 切合 实际 应 用 。 它 的 reduce 
函数 需 传人 当前 的 聚集 结果 以 及 要 进行 聚集 的 消息 。 该 接口 的 定义 如 下 : 


public interface ReducerAggregator«T» extends Serializable { 


T init(); 


T reduce(T curr, TridentTuple tuple); 


} 


O init eh Gk [n] —^4 TEA, reduce 15: Bac T2878 AY “SA fcurr, DX —" T TridentTuple 
类 型 的 消息 ， 返 回 值 也 为 一 个 T 类 型 的 值 。 


a 对 于 属于 同一 个 事务 的 消息 , 可 通过 不 断 调用 reduce 方 法 来 达到 聚集 消息 的 目标 。 用 户 通 


常 通过 实现 ReducerAggregator 接 口 来 实现 用 户 逻 辑 。 
ReducerAggitegatorImp1 类 实现 了 Aggregator 接 口 ， 它 可 作为 ReducerAggregator 的 执行 需 ， 其 


public class ReducerAggregatorImpl implements Aggregator<Result> { 


public ReducerAggregatorImpl(ReducerAggregator agg) { 


public void prepare(Map conf, TridentOperationContext context) ( 


11 public Result init(Object batchId, TridentCollector collector) { 


= new Result(); 


定义 如 下 : 
1 
2 ReducerAggregator agg; 
3 
4 
3 -3a88 = 385 
6 } 
7 
8 
9 } 
10 
12 Result ret 
13 ret.obj = _ 


14 return ret; 
15 } 


agg.init(); 
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17 public void aggregate(Result 


val, TridentTuple tuple, TridentCollector collector) ( 


18 val.obj = _agg.reduce(val.obj, tuple); 


19 } 


21 public void complete(Result val, TridentCollector collector) { 
22 collector.emit(new Values(val.obj)); 


23 } 


obj 对 象 中 。 


gator 接 口 与 Aggregator 接 口 的 
就 表明 在 聚集 的 过 程 中 并 不 会 


口 Result 类 中 只 包含 一 个 Object 类 型 的 成 员 变量 obj， 用 来 存储 聚集 结 
a 第 11~15 行 中 ，init 的 方法 实现 调用 了 _agg 的 init 方 法 ， 并 将 返回 值 存储 到 Result 类 中 的 


O 第 17~19 行 中 ，aggregate 的 实现 调用 了 _agg 的 reduce 方 法 。 这 里 可 以 看 出 ReducerAggre 


区 别 ， 即 reduce 方 法 中 并 不 需要 传人 TridentCollector 也 
回 外 发 送 消息 。 


20.3.2 ”CombinerAggregator 接 口 及 其 实现 


H 


CombinerAggregator 接 口 是 对 聚集 的 男 外 一 种 抽象 。 它 含有 一 个 combine 方 法 ,该 方法 的 收入 
参数 分 别 对 应 两 个 初步 的 聚集 结果 。 接 口 的 定义 如 下 : 


public interface CombinerAggregator«T» extends Serializable { 


T init(TridentTuple tuple); 
T combine(T vali, T val2); 
T zero(); 


} 


好 的 并 行 度 及 效率 。 


O 该 接口 会 对 事务 中 的 每 一 条 消 ， 
不 断 调 用 combine 方 法 将 初步 结果 进行 聚合 。 
口 CombinerAggregator 的 默认 值 会 调用 zero 方 法 获得 ， 与 ReducerAggregator 相 比 ， 它 具有 更 


息 调 用 init 方 法 ， 得 到 初步 的 聚集 结果 T， 然 后 在 此 基础 上 


CombinerAggregatorCombineImp1 类 是 CombinerAggregator 的 执行 器 ， 它 继承 自 Aggregator 接 


其 定义 如 下 : 


public class CombinerAggregatorCombineImpl implements Aggregator<Result> { 


CombinerAggregator agg; 


public CombinerAggregatorCombineImpl(CombinerAggregator agg) { 


1 

2 

3 

4 

5 .a88 = agg; 
6 } 

7 

8 


public void prepare(Map conf, 


9 } 


TridentOperationContext context) { 


11 public Result init(Object batchId, TridentCollector collector) { 


12 Result ret = new Result(); 
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13 ret.obj - agg.zero(); 

14 return ret; 

15 jJ 

16 

17 public void aggregate(Result val, TridentTuple tuple, TridentCollector collector) { 
18 Object v - tuple.getValue(0); 

19 if(val.obj==null) { 

20 val.obj = v; 

21 } else { 

22 val.obj = _agg.combine(val.obj, v); 

23 } 

24 ] 

25 

26 public void complete(Result val, TridentCollector collector) { 
27 collector.emit(new Values(val.obj)); 

28 } 


口 第 2 行 定义 成 员 变 量 agg， 为 CombinerAggregator 类 型 。 

O 第 11~15 行 实现 init 方 法 ， 它 调用 _agg 的 zero 方 法 来 获得 聚集 的 初始 值 。 

口 第 17~24 行 实现 aggregate 方 法 。 参 数 val 中 含有 目前 聚集 的 结果 ,参数 tuple 中 含有 另外 一 
个 聚集 的 结果 。 于 是 在 第 18 行 ， 从 第 1 列 获得 该 聚集 结果 ; 第 22 行 调用 agg 的 combine 方 法 
对 目前 聚集 结果 (val) 以 及 男 一 个 聚集 结果 (tuple) 进行 聚集 。 同 样 地 ，combine 方 法 并 
不 向 外 发 送 消息 。 

口 第 26~28 行 将 结果 发 送出 去 ， 目 前 结果 只 能 有 一 列 。 

口 接口 CombinerAggregator 和 ReducerAggregator 通 常会 与 ValueUpdater 接 口 一 起 工作 ， 以 完 

成 对 存储 的 更 新 。 


20.4 ”所 有 处 理 节点 的 上 下 文 


Trident 操 作 都 是 放 在 处 理 节点 中 执行 的 , 接 下 来 的 两 节 内 容 将 对 处 理 节点 进行 分 析 讨 论 。 处 
理 节点 会 被 放 入 Storm 的 Bolt 节 点 中 执行 , 每 个 Bolt 节 点 可 能 含有 多 个 处 理 节 点 。ProcessorContext 
类 的 Bolt 中 处理 节点 的 执行 的 上 下 文 环境 ，Bolt 中 的 每 一 个 处 理 节 点 可 以 利用 ProcessorContext 
中 state 变 量 存储 数据 。ProcessorContext 类 的 定义 如 下 : 


public class ProcessorContext { 
public Object batchId; 
public Object[] state; 
public ProcessorContext(Object batchId, Object[] state) { 
this.batchId = batchId; 
this.state - state; 
) 
} 


ProcessorContext 对 象 中 含有 以 下 两 个 成 员 。 
口 batchId: 事务 序号 。ITridentSpout 对 应 于 事务 尝试 消息 ( TransactionalAttemp )， 而 IRich 
Spout 中 则 为 RichspoutBatchId， 内 含 一 个 随机 数 。 
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O state: 对 象 数组 ， 保 存 了 该 Bolt 中 每 一 个 处 理 节 点 所 对 应 的 数据 。 理 解 该 成 员 变 量 何 时 
被 赋值 ， 以 及 何 时 使 用 是 很 关键 的 。 


该 对 象 在 SubTopologyBolt 类 的 initBatchState 方法 中 完成 初始 化 ， 相 关 代码 如 下 : 


@Override 
public Object initBatchState(String batchGroup, Object batchId) { 
ProcessorContext ret = new ProcessorContext(batchId, new Object[_nodes.size()]); 
for(TridentProcessor p: myTopologicallyOrdered.get(batchGroup)) { 
p.startBatch(ret); 
} 


return ret; 


} 


SubTopologyBolt 中 含有 一 系列 的 处 理 节 点 ， ee 
以 存储 数据 ， 这 个 对 象 即 为 ProcessorContext 的 对 象 数组 state 中 的 一 个 。 对 象 数组 state 的 大 小 
与 SubTopologyBolt 中 含有 节点 的 数目 相同 。 

每 个 处 理 节 点 的 startBatch 方 法 负责 将 上 下 文 对 象 传人 ,但 并 不 是 每 一 个 处 理 节 点 都 需要 存 
储 数据 。 另 外 ， 该 对 象 也 实现 了 SubTopologyBolt 内 部 处 理 节 点 之 间 的 数据 共享 。 

SubTopologyBolt 是 Trident 中 基本 的 Bolt 类 型 ， 详 情 参 见 第 26 章 。 


20.4.1 单个 处 理 节 点 的 上 下 文 


TridentContext 对 应 于 执行 TrdientProcessor 的 上 下 文 环境 
要 的 信息 ， 其 定义 如 下 : 


, 它 含有 该 处 理 节 点 输入 输出 所 需 


public class TridentContext { 
Fields selfFields; 
List«Factory» parentFactories; 
List«String» parentStreams; 
List«TupleReceiver» receivers; 
String outStreamId; 
int stateIndex; 
BatchOutputCollector collector; 

} 


该 类 中 各 个 成 员 的 含义 如 下 所 示 。 

口 selfFields 为 该 处 理 节点 新 产生 的 列 。 

口 parentFactories 和 parentStreams 分 别 为 该 节点 的 父 节 点 的 消息 模式 和 消息 对 应 的 流 。 
O receivers 表 明 哪 些 处 理 节点 将 接收 该 节点 产生 的 消息 。 

口 outStreamId 为 该 节点 的 输出 消息 流 。 

O stateIndex 为 该 处 理 节点 的 编号 ， 为 SubTopologyBolt 中 的 统一 编号 。 

口 collector 用 来 问 外 发 送 消息 。 
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20.4. ”操作 执行 的 上 下 文 


TrdientOperationContext 为 Trident 的 操作 提供 了 上 下 文 。 它 包含 两 个 参数 : _factory 用 来 创 


建 输入 ，_topoContext 对 象 中 含有 Topology 的 上 下 文 信息 。 相 关 代 码 如 下 : 


public class TridentOperationContext implements IMetricsContext{ 
TridentTuple.Factory factory; 
TopologyContext  topoContext; 


Trident 的 操作 有 时 是 需要 了 人 解 Topology 的 上 下 文 的 ( 例如， 当前 Task 的 编号 等 )。 


20.5 Trident 的 输出 收集 器 


TiridentCollector 接 口 主要 用 于 向 外 发 送 处 理 节点 的 数据 。 由 于 一 个 处 理 
是 另外 一 个 节点 的 输入 , 故 其 输出 并 不 一 定 意味 着 真正 地 将 消息 发 送出 去 , 它 可 能 会 直接 调用 下 


IET a Fr HEE 


一 个 处 理 节 点 的 execute 方 法 以 完成 当前 节点 的 消息 输出 。 通 过 这 种 方式 ， 各 个 节点 形成 了 一 条 


调用 链 ， 并 最 终 完 成 对 消息 的 处 理 。 


TridentCollector 接 口 主要 定义 了 emit 方 法 和 reportError 方 法 ， 其 定义 如 下 : 


public interface TridentCollector { 
void emit(List«Object» values); 
void reportError(Throwable t); 


} 


20.5.1 FreshCollector 


FreshCollector 类 的 emit 方 法 会 根据 输入 的 values 来 创建 消息 ， 并 调用 该 消息 的 接收 端 处 理 


节点 来 执行 该 消息 。FreshCollector 的 定义 如 下 : 


public class FreshCollector implements TridentCollector { 
FreshOutputFactory factory; 
TridentContext _triContext; 
ProcessorContext context; 


public FreshCollector(TridentContext context) { 

 triContext - context; 

factory - new FreshOutputFactory(context.getSelfOutputFields()); 
) 


public void setContext(ProcessorContext pc) { 
this.context - pc; 
) 


@Override 
public void emit(List<Object> values) { 
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TridentTuple toEmit = factory.create(values); 
for(TupleReceiver r: _triContext.getReceivers()) { 

r.execute(context, triContext.getOutStreamId(), toEmit); 
} 


20.5.2 CaptureCollector 


CaptuerCollector 类 的 emit 方 法 被 调用 时 ， 只 是 将 消息 放 在 缓存 中 ， 并 不 真正 发 送出 去 。 该 
类 的 定义 如 下 : 


public class CaptureCollector implements TridentCollector { 
public List«List«Object»» captured - new Arraylist(); 


@Override 


public void emit(List<Object> values) { 
this.captured.add(values) ; 
} 


20.5.3 GroupCollector 


GroupCollector 主 要 用 于 分 组 操作 ， 负 责 缓存 分 组 的 消息 。 其 中 ，emit 方 法 传人 的 values 为 除 
了 用 于 分 组 外 的 消息 的 其 他 部 分 GroupCollector 可 以 减少 内 存 占 用 并 提高 效率 。 该 类 的 定义 如 下 : 


public class GroupCollector implements TridentCollector { 
public List«Object» currGroup; 


ComboList.Factory factory; 
TridentCollector collector; 


public GroupCollector(TridentCollector collector, ComboList.Factory factory) { 
. factory = factory; 
collector - collector; 


} 


(QOverride 
public void emit(List<Object> values) { 
List[] delegates - new List[2]; 
delegates[0] = currGroup; 
delegates[1] = values; 
. collector.emit( factory.create(delegates)); 


} 
注意 ，emit 方 法 将 缓存 的 currGroup 与 values 合 并 后 发 送 。 
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20.5.4 AppendCollector 


对 于 输入 的 一 条 消息 , AppendCollector 类 可 能 会 产生 多 条 消息 , 并 且 新 产生 的 消息 都 要 包含 
输入 消息 的 所 有 列 的 情况 。 该 类 主要 使 用 0peration0utputFactory 对 输入 消息 和 产生 的 消息 进行 
连接 。AppendCollector 类 的 定义 如 下 : 


1 public class AppendCollector implements TridentCollector { 

2 OperationOutputFactory factory; 

3 TridentContext  triContext; 

4 TridentTuple tuple; 

5 ProcessorContext context; 

6 

7 public AppendCollector(TridentContext context) { 

8  triContext - context; 

9 factory - new OperationOutputFactory(context.getParentTupleFactories().get(0), 
context.getSelfOutputFields()); 

10 } 

11 

12 public void setContext(ProcessorContext pc, TridentTuple t) ( 

13 this.context - pc; 

14 this.tuple - t; 

15 j 

16 

17 @Override 

18 public void emit(List<Object> values) { 

19 TridentTuple toEmit = _factory.create((TridentTupleView) tuple, values); 

20 for(TupleReceiver r: _triContext.getReceivers()) { 

21 r.execute(context, triContext.getOutStreamId(), toEmit); 

22 } 

23 } 

24 


25 @Override 

26 public void reportError(Throwable t) { 

27 _triContext.getDelegateCollector().reportError(t) ; 
28 } 


O 第 4 行 的 成 员 变 量 tuple 表 示 产 生 的 消息 的 前 级 。 

a 第 18~23 行 在 发 送 消 息 values 时 ， 首 先 利 用 _factory 将 成 员 tuple 与 输入 消息 values 进 行 连 
接 以 得 到 新 的 消息 ， 然 后 根据 上 下 文 对 象 获 得 该 消息 的 接收 处 理 节点 ， 并 最 终 调用 这 些 
节点 的 execute 方 法 对 输出 消息 进行 处 理 。 

O 第 13~15 行 的 setContext 方 法 对 tuple 变 量 以 及 context 进 行 设置 。 顾 名 思 义 ，context 为 产 

生 的 消息 的 上 下 文 ， 即 消息 的 前 级 。 


20.5.5 AddIdCollector 


Trident 在 进行 数据 处 理 时 ， 消 息 中 并 不 包含 事务 序号 的 信息 ， 但 在 Storm 中 进行 消息 传输 ， 
却 都 是 以 事务 序号 作为 第 1 列 的 列 值 的 。AddIdCollector 对 发 送 消息 的 操作 进行 了 简单 的 封装 , 当 
AddIdCollector 发 送 消 息 时 ， 事 务 序号 被 添加 到 第 1 列 ， 之 后 消息 才 发 送出 去 。AddIdCollector 类 
的 定义 如 下 : 
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private static class AddIdCollector implements TridentCollector { 
BatchOutputCollector delegate; 
Object id; 
String stream; 


public AddIdCollector(String stream, BatchOutputCollector c) ( 
. delegate = c; 
Stream - stream; 


) 


public void setBatch(Object id) { 
id = id; 
} 


(QOverride 

public void emit(List<Object> values) { 
 delegate.emit( stream, new ConsList( id, values)); 

} 


@Override 

public void reportError(Throwable t) { 
. delegate.reportError(t); 

} 


} 


O AddIdCollector 类 实现 了 TridentCollector 接 口 ,并 包含 BatchoutputCollector 的 代理 。id 
表示 为 当前 事务 所 对 应 的 事务 序号 ，_stream 表 示 消 息 发 送 的 目标 流 。emit 方 法 中 会 新 产 
生 一 个 ConsList 对 象 ， 它 负责 将 id 与 values 连 接 起 来 。 

O 与 TridentTupleView 的 实现 类 似 ， 这 里 并 不 会 创建 一 个 新 的 列表 ， 而 是 重 载 AbstractList 的 
get 方 法 , 在 请 求 下 标 为 0 时 返回 txid， 其 他 情况 返回 values 中 的 数据 。 目 前 , 这 种 Trident 
Collector 只 是 被 TridentSpoutExecutor 使 用 a 


20.6 Trident 的 处 理 节点 


接口 TridentProcessor 是 Trident 对 操作 执行 的 抽象 , 其 类 关系 如 图 20-3 所 示 。 该 接口 是 将 Bolt 
节点 中 各 个 操作 连接 在 一 起 的 核心 。 


I TupleReceiver 


| 


1 TridentProcessor 


ee 
1 


图 20-3 ”TridentProcessor 接 口 及 其 实现 类 
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其 中 的 基本 接口 以 及 基本 实现 类 介绍 如 下 。 

口 TupleReceiver: 对 基本 的 消息 处 理 进 行 抽象 。 

口 TridentProcessor: 对 基本 的 事务 消息 处 理 进 行 抽象 。 

O EachProcessor: 会 对 消息 进行 逐条 处 理 的 处 理 节 点 。 

口 ProjectedProcessor: 对 映射 消息 进行 操作 的 处 理 节 点 。 

口 PartitionPersistProcessor: 分 区 存储 的 处 理 节点 ， 它 会 将 数据 存储 于 State 对 象 中 。 
口 StateQueryProcessor: State 查 询 处 理 节点 ， 主 要 用 于 DRPC。 

O MultiReducerProcessor: 处 理 多 流 情况 的 TridentProcessof， 详 情 请 参见 22.4 节 。 


20.6.1 TridentProcessor 接 口 
首先 来 看 TupleReceiver 接 口 的 定义 : 


public interface TupleReceiver { 
void execute(ProcessorContext processorContext, String streamId, TridentTuple tuple); 
i 


该 接口 中 定 了 execute 方 法 ， 其 输入 为 TridentTuple 和 该 消息 所 对 应 的 流 号 。Bolt 中 的 各 个 操 
作 ， 就 是 通过 TupleReceiver 的 实例 串 接 起 来 的 (操作 需 属 于 同一 个 Bolt )。 
TridentProcessor 接 口 扩展 了 TupleReceiver 接 口 ， 其 定义 如 下 : 


public interface TridentProcessor extends Serializable, TupleReceiver { 
void prepare(Map conf, TopologyContext context, TridentContext tridentContext); 
void cleanup(); 
void startBatch(ProcessorContext processorContext); 
void finishBatch(ProcessorContext processorContext); 
Factory getOutputFactory(); 
} 


TridentProcessor 是 Trident 对 于 事务 处 理 操 作 的 抽象 。 事务 开始 时 , 调用 startBatch 方 法 , 并 
在 处 理 属于 一 个 事务 的 消息 时 ， 调 用 execute 方 法 。 事 务 处 理 结束 后 ， 则 调用 finishBatch 方 法 。 
TridentProcessor 的 生命 周期 与 Bolt 相 同 , 在 Bolt 被 创建 的 时 候 调用 prepare 方 法 , Bolt 销毁 的 时 候 
调用 cleanup 方 法 。get0utputFactory 方 法 用 于 返回 该 处 理 节点 的 输出 模式 。 

接 下 来 我 们 将 介绍 几 种 处 理 节 点 的 重要 实现 。 


20.6.2 PartitionPersistProcessor 


PartitionPersistProcessor 类 会 将 一 个 事务 中 的 数据 以 特定 的 方式 写 人 到 存储 对 象 中 ， 其 定 
义 如 下 : 


public class PartitionPersistProcessor implements TridentProcessor { 
StateUpdater _updater; 
State state; 
String stateId; 
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TridentContext context; 

Fields inputFields; 

ProjectionFactory projection; 

FreshCollector collector; 

public PartitionPersistProcessor(String stateId, Fields inputFields, StateUpdater updater) { 
Updater = updater; 
 stateld = stateld; 
_inputFields = inputFields; 


} 


上 述 代码 中 ， 成 员 变 量 及 构造 函数 的 含义 如 下 。 

O State 类 型 的 _state 对 象 为 数据 的 存储 目标 。 

口 StateUpdater 类 型 的 _updater 对 象 为 数据 的 存储 方法 ， 即 如 何 更 新 State 对 象 。_stateId 
用 来 获取 State 对 象 。 

口 _inputFileds 和 projection 对 象 用 于 产生 数据 。 

接 下 来 讨论 其 主要 的 方法 实现 ， 相 关 代码 如 下 : 


1 public class PartitionPersistProcessor implements TridentProcessor { 

2 @Override 

3 public void prepare(Map conf, TopologyContext context, TridentContext tridentContext) { 

4 List<Factory> parents = tridentContext.getParentTupleFactories(); 

5 if(parents.size()!=1) { 

6 throw new RuntimeException("Partition persist operation can only have one parent"); 
7 
8 
9 


} 
_context = tridentContext; 
state = (State) context.getTaskData( stateId); 
10 projection = new ProjectionFactory(parents.get(0),  inputFields); 
11 collector - new FreshCollector(tridentContext); 
12 _updater.prepare(conf, new TridentOperationContext(context,  projection)); 
13 } 
14 


15 @Override 

16 public void startBatch(ProcessorContext processorContext) { 

17 processorContext.state[ context.getStateIndex()] = new ArrayList<TridentTuple>(); 
18 } 


20 @Override 
21 public void execute(ProcessorContext processorContext, String streamId, TridentTuple 


tuple) { 
22 ((List) processorContext.state[_context.getStateIndex()]).add(_projection.create 
(tuple)) 
23 } 
24 


25 @Override 
26 public void finishBatch(ProcessorContext processorContext) { 


27 _collector.setContext (processorContext) ; 

28 Object batchId = processorContext.batchId; 

29 // since this processor type is a committer, this occurs in the commit phase 

30 List«TridentTuple» buffer = (List) processorContext.state[ context.getStateIndex()]; 
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32 // don't update unless there are tuples 

33 // this helps out with things like global partition persist, where multiple tasks 
may still 

34 // exist for this processor. Only want the global one to do anything 

35 // this is also a helpful optimization that state implementations don't need 
to manually do 

36 if(buffer.size() > 0) ( 

37 Long txid - null; 

38 // this is to support things like persisting off of drpc stream, 

which is inherently unreliable 

39 // and won't have a tx attempt 

40 if(batchId instanceof TransactionAttempt) { 

41 txid = ((TransactionAttempt) batchId).getTransactionId(); 

42 

43 _state.beginCommit(txid) ; 

44  updater.updateState( state, buffer, collector); 

45 .State.commit(txid); 

46 } 

47 } 

48 } 


O 第 3~13 行 实现 prepare 方 法 。 第 9 行 根据 _stateId 获 得 存储 对 象 ， 该 对 象 是 从 Topology 
Context 上下文 对 象 中 获得 的 。 初 始 化 SubTopologyBolt 时 ,对 state 对 象 进行 了 集中 的 创建 。 


列表 中 。 


第 4~7 行 表示 该 处 理 节点 不 允许 存在 多 个 父 节 点 ， 这 是 显然 的 。 

O 第 16~18 行 实现 startBatch 方 法 。 ProcessorContext 对 象 中 的 state 成 员 用 来 存储 局 部 数据 ， 
这 里 将 其 初始 化 为 TridentTuple 类 型 的 列表 。 

a 第 21~23 行 的 execute 方 法 实现 中 ,仅仅 是 将 输入 消息 放 进 了 processorContext 对 象 的 state 


O 第 26~47 行 在 finishBatch 方 法 中 对 state 对 象 进行 更 新 。 即 第 44~45 行 分 别 调用 state 对 象 


的 beginCommit 方 法 、_update 对 象 的 updateState 方 法 以 及 _state 对 象 的 commit 方 法 。 第 36 


行进 行 了 检测 ， 若 无 数据 则 不 进行 更 新 操作 以 提高 效率 。 


a 目前 的 实现 是 较为 简单 的 ， 更 为 直观 的 设计 为 : 在 事务 开始 时 ， 调 用 beginCommit 方 法 ， 


在 处 理 消息 时 


， 调 用 updatestate 方 法 ， 在 习 


BS 结束 时 ， 调 用 commit 方 法 。 出 于 对 性 能 的 


考虑 ， 该 实现 为 批 处 理 模式 ， 即 在 finishBatch 中 进行 一 次 集中 的 更 新 。 


20.6.3 StateQueryProcessor 


与 PartitionPersistProcessor 相 对 应 ，StateQueryProcessor 用 于 查询 存储 对 象 。 由 于 它们 都 
需要 对 存储 对 象 进行 操 作 ， 这 两 种 TridentProcessor 会 被 放 在 同一 个 Bolt 节 点 中 执行 。 首先 来 看 
该 类 的 主要 成 员 变 量 ， 代 码 如 下 : 


public class StateQueryProcessor implements TridentProcessor { 
QueryFunction function; 


State state; 


String stateId; 
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TridentContext context; 
Fields inputFields; 
ProjectionFactory projection; 
AppendCollector collector; 


public StateQueryProcessor(String stateId, Fields inputFields, QueryFunctionfunction) { 
_stateId = stateld; 
_function = function; 
_inputFields = inputFields; 


} 
下 面 来 介绍 各 个 成 员 变 量 的 含义 。 


Context 中 获取 _state 对 象 。 


下 面 讨论 其 主要 的 方法 实现 ， 代 码 如 下 : 


1 public class StateQueryProcessor implements TridentProcessor { 

2 @Override 

3 public void prepare(Map conf, TopologyContext context, TridentContext tridentContext) 
4 List<Factory> parents = tridentContext.getParentTupleFactories(); 

5 if(parents.size()!=1) { 

6 throw new RuntimeException("State query operation can only have one parent"); 
7 
8 
9 


} 
_context = tridentContext; 
state = (State) context.getTaskData( stateId); 
10 projection = new ProjectionFactory(parents.get(0),  inputFields); 
11 collector - new AppendCollector(tridentContext); 
12 _function.prepare(conf, new TridentOperationContext(context,  projection)); 
13 } 
14 


15 @Override 

16 public void startBatch(ProcessorContext processorContext) { 

17 processorContext.state[_context.getStateIndex()] = new BatchState(); 
18 } 


20 @Override 


O QueryFunction 类 型 的 _function 对 象 用 于 查询 存储 对 象 ， 而 _stateId 则 用 于 在 Topology 


口 inputFields 和 _projection 对 象 用 于 构建 function 的 输入 消息 。 collector 则 用 于 收集 输出 。 


{ 


21 public void execute(ProcessorContext processorContext, String streamId, TridentTuple tuple) { 


22 BatchState state - (BatchState) processorContext.state[ context.getStateIndex()]; 
23 state.tuples.add(tuple); 

24 state.args.add( projection.create(tuple)); 

25 ] 

26 


27 @Override 
28 public void finishBatch(ProcessorContext processorContext) { 


29 BatchState state = (BatchState)processorContext.state[ context.getStateIndex()]; 
30 if(!state.tuples.isEmpty()) { 

31 List<Object> results = _function.batchRetrieve(_state, state.args); 

32 if(results.size()!=state.tuples.size()) { 

33 throw new RuntimeException("Results size is different 


" " " 


than argumentsize: " + results.size() + " vs " + state.tuples.size()) 


B 
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34 } 

35 for(int i=0; i«state.tuples.size(); i++) { 

36 TridentTuple tuple = state.tuples.get(i); 

37 Object result = results.get(i); 

38 _collector.setContext(processorContext, tuple); 

39 _function.execute(_projection.create(tuple), result, collector); 
40 } 

41 } 

42 } 

43 

44 private static class BatchState { 

45 public List<TridentTuple> tuples = new ArrayList<TridentTuple>(); 
46 public List<TridentTuple> args = new ArrayList<TridentTuple>(); 
47 } 

48 ] 


口 第 3~13 行 实现 prepare 方 法 ， 它 会 根据 stateId 获 取 存 储 对 象 。 

口 第 44~47 行 为 该 处 理 节 点 在 ProcessorContext 中 存储 的 数据 结构 ，tuples 表 示 输 入 的 消息 ， 
而 args 则 是 输入 消息 中 的 某 些 列 , 代表 了 QueryFunction 的 查询 参数 。 StateQueryProcessor 
在 得 到 查询 结果 后 ， 需 要 以 某 种 方式 将 结果 返回 ， 于 是 在 QueryFunction 的 execute 方 法 中 
就 需要 传人 原始 的 消息 ， 即 需要 在 存储 中 保存 原始 的 消息 。 这 样 做 是 有 意义 的 ， 例 如 在 
含有 DRPC 的 Topology 中 ，StateQueryProcessor 收 到 的 消息 中 可 能 含有 两 列 :< 查询 消息 来 20 
源 ， 查 询 参 数 >， 消 息 来 源 需 要 在 所 有 处 理 节点 中 被 保存 ， 以 使 得 最 终结 果 可 以 返回 给 
DRPC 的 服务 器 。 

O 第 16~18 行 的 startBatch 方 法 将 processorContext 中 的 state 对 象 初始 化 为 BatchState 对 象 。 

O 第 21~25 行 的 execute 方 法 将 输入 的 消息 存 和 人 Batchstate 对 象 中 , 其 中 args 是 通过 projec tion 

对 象 的 映射 方法 得 到 的 。 

口 第 28~42 行 的 finishBatch 方 法 对 state 进 行 了 查询 。 第 31 行 调用 QueryFunction 对 象 的 batch 

Retrieve 方 法 对 state 对 象 进行 查询 。 第 32~34 行 对 结果 进行 验证 , 即 任何 一 条 查询 均 需 要 

有 结果 返回 , 并 且 是 一 对 一 的 。 第 35~40 行 对 每 一 条 返回 结果 调用 QueryFunction 的 execute 

方法 ， 将 结果 发 送 到 下 一 个 节点 或 者 存储 。 


20.7 ”聚集 器 的 执行 


有 了 前 面 关于 处 理 节点 的 讨论 后 , 本 节 来 讨论 聚集 需 是 如 何 被 Trident 执 行 的 这 一 问题 。 用 户 
实现 的 Aggregator 需 要 放置 在 处 理 节点 中 运行 。 

AggtegatepProcessor 是 其 中 的 一 个 执行 器 , 它 继 承 自 TridentpProcessor 接 口 ， 主 要 用 来 执行 聚 
集 锅 ， 其 代码 如 下 : 


1 public class AggregateProcessor implements TridentProcessor { 
2 Aggregator agg; 

3 TridentContext context; 

4 FreshCollector collector; 
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5 Fields inputFields; 
6 ProjectionFactory projection; 
7 
8 public AggregateProcessor(Fields inputFields, Aggregator agg) ( 
9 _a88 = agg; 
10  inputFields - inputFields; 
11 } 
12 
13 @Override 
14 public void prepare(Map conf, TopologyContext context, TridentContext tridentContext) { 
15 List<Factory> parents = tridentContext.getParentTupleFactories(); 
16 if(parents.size()!=1) { 
17 throw new RuntimeException("Aggregate operation can only have one parent"); 
18 } 
19 _context = tridentContext; 
20 _collector = new FreshCollector(tridentContext) ; 
21 projection = new ProjectionFactory(parents.get(0),  inputFields); 
22  agg.prepare(conf, new TridentOperationContext(context, _projection)); 
23 
24 
25 @Override 
26 public void cleanup() { 
27 _agg.cleanup(); 
28 } 
29 
30 @Override 
31 public void startBatch(ProcessorContext processorContext) { 
32 _collector.setContext (processorContext) ; 
33 processorContext.state[_context.getStateIndex()] = _agg.init 
(processorContext.batchId, collector); 
34 j 
35 
36 @Override 
37 public void execute(ProcessorContext processorContext, String streamId, TridentTupletuple){ 
38 . collector.setContext(processorContext); 
39  agg.aggregate(processorContext.state[ context.getStateIndex()], projection 
.create(tuple), collector); 
40 } 
41 
42 GOverride 
43 public void finishBatch(ProcessorContext processorContext) { 
44 . collector.setContext(processorContext); 
45  agg.complete(processorContext.state[ context.getStateIndex()], collector); 
46 
47 
48 @Override 
49 public Factory getOutputFactory() { 
50 return collector.getOutputFactory(); 
51 } 
52 } 
理解 该 类 的 重点 在 于 分 析 聚 集结 果 存 储 在 什么 地 方 以 及 如 何在 TridentProcessor 的 相应 接口 


方法 中 调用 聚集 器 的 方法 等 。 下 面 简要 介绍 上 述 代码 的 作用 。 
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口 第 22 行 ， 在 TridentProcessor 的 prepare 方 法 中 调用 聚集 器 的 prepare 方 法 ,传人 的 参数 为 

一 个 用 于 产生 输入 的 工厂 方法 ， 以 及 处 理 节 点 的 上 下 文 对 象 。 

O 第 33 行 ， 在 TridentProcessor 的 startBatch 方 法 中 ， 调 用 聚集 器 的 init 方 法 。 完 成 对 一 个 

事务 的 初始 化 ， 初 始 化 结果 存储 于 所 有 处 理 节 点 的 上 下 文 对 象 中 。 

口 第 39 行 ， 在 TridentpProcessor 的 execute 方 法 中 调用 聚集 器 的 aggregate 方 法 进行 聚集 。 传 
入 的 参数 为 当前 聚集 结果 ， 以 及 要 被 聚集 的 消息 ; 新 的 聚集 结果 将 被 存 人 处理 节点 的 上 
下 文 对 象 中 。 

口 第 45 行 ,在 TridentpProcessor 的 finishBatch 方 法 中 ， 调 用 聚集 器 的 complete 方 法 。 根 据 聚 

集 器 的 具体 实现 , 此 处 可 能 会 将 消息 发 送出 去 , 故 需 传人 一 个 输出 收集 器 对 象 _collector。 

口 在 这 些 方法 中 ,经常 要 设置 当前 的 上 下 文 对 象 , 因为 一 个 TridentProcessor 可 能 会 处 理 来 

自 事务 的 消息 ( 如 含有 DRPC 查 询 的 Topology )。 


第 21 章 
Trident 流 的 基本 操作 


流 是 Trident 的 核心 概念 ，Trident 提 供 了 关于 流 的 多 种 操作 。Trident 将 这 些 流 的 操作 对 应 到 了 
一 张 有 向 图 上 ,通过 添加 节点 和 有 回 边 来 反映 操作 的 变动 。 然 后 ，Trident 会 根据 这 张 有 向 图 来 对 
执行 进行 优化 ， 并 最 终 将 其 编译 成 为 Topology， A ques 

对 用 户 而 言 ，Trident 隐 藏 了 基本 的 Spout 和 了 Bolt 的 概念 。 过 流 操作 的 概念 来 完成 对 逻辑 的 
抽象 ， hi Vo de 

本 章 将 对 单一 流 的 基本 操作 进行 介绍 ， 下 一 章 将 进一步 讨论 多 个 流 之 间 的 操作 。 


本 节 介 绍 流 的 成 员 变量 以 及 一 些 基础 方法 ， 这 些 是 理解 Trident 流 的 基础 。 
21.1.1. 流 的 成 员 变 量 


从 其 成 员 变量 可 以 看 出 ， 流 是 与 节点 (Node) 相对 应 的 。Steam 类 的 定义 如 下 : 


public class Stream implements IAggregatableStream { 
Node node; 
TridentTopology topology; 
String name; 


口 流 中 包含 了 一 个 Node 类 型 的 节点 _node， 以 及 流 的 名 字 _name。 

O 同时 , 流 中 还 包含 了 一 个 TridentTopology 的 引用 _topology。TridentTopology 中 有 一 个 有 
向 图 _graph， 该 图 以 流 中 _node 节 点 为 图 顶点 。 关 于 节点 类 型 Node， 我 们 会 在 其 他 章节 进 
行 分 析 。 


21.1.2 ” 流 节 点 名 字 


name PRA zz^E KT, 它 根据 前 面 介绍 的 _topology 和 _node 两 个 成 员 变 量 来 完成 构建 过 
程 ,相当 于 为 当前 _node 节 点 赋予 一 个 名 字 。 由 于 Trident 会 将 相关 的 处 理 节 点 放 在 一 个 Bolt 中 运行 ， 
节点 的 名 字 就 很 关键 了 ， 它 可 以 用 于 获知 哪些 操作 是 在 哪些 Bolt 节 点 上 运行 的 。 其 代码 如 下 : 
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public Stream name(String name) ( 
return new Stream( topology, name, node); 
} 


“PALEY PAS eR A FR Bolt £x HJZH f S , Ze fkEStorm UI 上 显示 的 Bolt 名 
相关 代码 如 下 : 


1 private static Map«Group, String» genBoltIds(Collection<Group> groups) ( 
2 Map«Group, String» ret - new HashMap(); 

3 int ctr = 0; 

4 for(Group g: groups) { 

5 if(lisSpoutGroup(g)) { 

6 List«String» name = new ArrayList(); 

7 name.add("b"); 

8 


name.add("" + ctr); 
9 String groupName - getGroupName(g); 
10 if(groupName!-null 8& !groupName.isEmpty()) ( 
11 name. add (getGroupName(g)) ; 
12 ) 
13 ret.put(g, Utils.join(name, "-")); 
14 ctr++; 
15 } 
16  ) 
17 return ret; 
18 } 
19 


20 private static String getGroupName(Group g) { 
21 TreeMap«Integer, String» sortedNames - new TreeMap(); 
22 for(Node n: g.nodes) 1 


23 if(n.name!-null) ( 

24 sortedNames.put(n.creationIndex, n.name); 
25 } 

26 } 


27 List<String> names = new ArrayList<String>(); 
28 String prevName = null; 
29 for(String n: sortedNames.values()) { 


30 if(prevName==null || !n.equals(prevName)) { 
31 prevName = n; 

32 names.add(n) ; 

33 } 

34 } 

35 return Utils.join(names, "-"); 

36 } 


O 第 20 行 定义 getGroupName 函 数 ， 输 入 为 一 个 节点 组 g。 

O 第 21~27 行 按照 创建 序号 ( creationIndex ) 对 节点 的 名 字 进 行 排序 ， 创 建 序号 基本 上 与 节 
点 拓扑 排序 的 顺序 的 是 一 致 的 ， 它 反映 了 节点 处 理 的 先后 顺序 。 

口 第 27~35 行 将 节点 名 字 用 “-” 连 接 起 来 ,并 进行 简单 的 前 后 去 重 。 通常 ,使 每 个 节点 均 拥 
有 一 个 独特 的 名 字 会 更 利于 调试 ， 默 认 的 情况 下 名 字 为 空 。 

O 第 1 行 定义 的 getBoltIds 方 法 用 于 获得 每 一 个 节点 组 所 对 应 的 Bolt 节 点 名 (节点 的 ID )， 默 
认 的 模式 为 : b-[ 标 号 ]-[getGroupname]。 当 getGroupName 为 null 时 , 节点 的 ID 只 为 b-[ 标 号 ]。 
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目前 ，Spout 节 点 的 名 字 只 能 为 spout-[ 标 号 ]， 如 下 面 的 函数 所 示 : 


private static Map«Node, String» genSpoutIds(Collection«SpoutNode» spoutNodes) { 
Map«Node, String» ret - new HashMap(); 
int ctr = 0; 
for(SpoutNode n: spoutNodes) { 
ret.put(n, "spout" + ctr); 
ctr++; 


} 


return ret; 


21.1.3” 流 的 映射 检查 


oo 发 点 , 根据 相应 的 操作 来 创建 新 节点 的 , newStream#linewDRPCStream 
用 来 创建 最 原始 节点 。 

ea 当前 节点 创建 的 具有 目标 输出 列 的 新 节点 是 否 合法 ， 
即 需 要 projFields 中 的 所 有 字段 名 都 出 现在 当前 节点 的 输出 列 中 。 该 函数 的 定义 如 下 : 


private void projectionValidation(Fields projFields) { 
f (projFields == null) { 
return; 
} 


Fields allFields = this.getOutputFields(); 
for (String field : projFields) { 
if (lallFields.contains(field)) { 
throw new IllegalArgumentException("Trying to select non-existent field: 
'" + field + "' from stream containing fields fields: «" + allFields + ">"); 


} 
} 
} 
许多 流 操作 都 需要 进行 projectionValidation 这 项 检查 。 


21 .1 .4 添加 节点 


addSourcedNoed 限 数 在 TridentTopology 类 中 定义 ， 主 要 被 流 和 分 组 流 中 的 方法 调用 。 分 组 流 
是 一 种 特殊 的 流 ， 其 中 的 消息 会 按照 某 些 域 进行 分 组 。 该 函数 的 定义 如 下 : 


1 protected Stream addSourcedNode(Stream source, Node newNode) { 

2 return addSourcedNode(Arrays.asList(source), newNode) ; 

3 } 

4 protected Stream addSourcedNode(List<Stream> sources, Node newNode) { 
5 registerSourcedNode(sources, newNode) ; 

6 return new Stream(this, newNode.name, newNode) ; 

7 

8 


} 
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9 protected void registerSourcedNode(List<Stream> sources, Node newNode) { 
10 registerNode(newNode); 

11 int streamIndex = 0; 

12 for(Stream s: sources) ( 


13  graph.addEdge(s. node, newNode, new IndexedEdge(s. node, newNode, streamIndex)); 
14 streamIndex++; 

15  } 

16 } 

17 

18 protected void registerNode(Node n) { 

19 _graph.addVertex(n); 

20 if(n.stateInfo!-null) { 

21 String id = n.stateInfo.id; 

22 if(!_colocate.containsKey(id)) { 

23 _colocate.put(id, new ArrayList()); 
24 } 

25 _colocate.get(id).add(n); 

26 } 

27 } 


O 第 9~16 行 定义 的 registerSourcedNode 用 来 向 图 中 添加 新 节点 。 

口 第 12~15 行 为 每 一 个 sources 中 的 流 中 节点 建立 一 条 到 新 节点 的 边 。 注 意 ，sources 代 表 了 
新 节点 的 所 有 父 节 点 ， 此 处 会 依据 streamIndex 对 这 些 父 节点 进行 标号 。 第 10 行 调用 
registerNode 添 加 新 节点 ， 该 方法 在 第 18~27 行 中 定义 。 除 在 第 19 行 向 图 中 添加 一 个 顶点 
外 ， 若 节点 中 的 stateInfo 成 员 不 为 空 ， 则 将 该 节点 放 人 与 存储 序号 (StateId ) 相对 应 的 
哈 希 表 _colocate 中 。_colocate 变 量 将 所 有 访问 同一 存储 的 节点 关联 在 一 起 ， 并 将 他 们 放 
在 一 个 Bolt 闻 点 中 执行 。 

O 第 4~7 行 定义 addSoucedNode 方 法 , 除 利用 registerSourcedNode 方 法 创建 新 节点 外 ,还 会 利 

用 新 节点 产生 一 个 流 并 返回 。 用 户 会 对 返回 的 流 作 进一步 操作 ， 进 而 创建 更 多 的 子 节点 、 

更 多 的 边 ， 这 样 ， 对 流 的 操作 便 构 成 了 有 向 图 。 


21.2 BAIE 
流 映 射 操作 比较 简单 ， 用 于 过 滤 输 入 流 中 的 某 些 域 ， 从 而 产生 一 个 新 的 流 。 


public Stream project(Fields keepFields) { 
projectionValidation(keepFields); 
return topology.addSourcedNode(this, new ProcessorNode( topology.getUniqueStreamId(), 
name, keepFields, new Fields(), new ProjectedProcessor(keepFields))); 


} 

口 流 的 映射 操作 是 根据 当前 的 流 及 要 保留 的 域 keepFields 来 创建 一 个 新 流 的 ， 该 流 以 一 个 

ProcessorNode 作 为 节点 。 

口 ProcessorNode 中 含有 一 个 ProjectedProcessor,， 用 来 对 输入 的 消息 进行 过 滤 ， 从 而 得 到 需 
要 的 列 。pProjectedProcessor 为 TridentProcessor 类 型 ， 用 来 执行 映射 操作 。 
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a 映射 操作 操作 会 在 图 中 创建 新 的 节点 。 


21.3 流 的 分 组 操作 
流 的 分 组 ( groupBy ) 操作 是 非常 关键 的 ， 该 操作 返回 一 个 分 组 流 ， 相 关 代码 如 下 : 


public GroupedStream groupBy(Fields fields) { 
projectionValidation(fields); 
return new GroupedStream(this, fields); 


} 
groupBy 操 作 会 创建 一 个 分 组 流 ， 分 组 流 中 含有 当前 的 流 引 用 以 及 指定 对 哪些 域 进 行 分 组 并 
作为 成 员 变 量 的 信息 。 
groupBy 操 作 并 不 会 创建 新 的 节点 ， 且 分 组 流 上 进行 的 操作 都 是 以 分 组 的 列 作为 聚合 单位 的 。 
分 组 流 是 多 流 操作 的 核心 ,最终 会 通过 添加 分 区 节点 的 方式 转换 成 为 流 。 在 Trident 底 层 , 将 
通过 域 分 组 方式 (Fields Grouping ) 完成 ， 域 分 组 所 采用 的 域 即 为 分 组 流 的 域 ， 这 样 具 有 相同 分 
组 域 的 消息 就 可 以 到 达 相 同 的 节点 。 


21.4 流 的 逐 行 操作 


each 操 作 表 示 对 输入 的 每 行 消息 进行 处 理 ， 通 常 表示 一 条 消息 的 处 理 与 其 他 消息 无 关 ， 该 操 
作 的 代码 如 下 : 


1 public Stream each(Fields inputFields, Function function, Fields functionFields) { 
2 projectionValidation(inputFields); 

3 return topology.addSourcedNode(this, 

4 new ProcessorNode( topology.getUniqueStreamId(), 

5 name, 

6 TridentUtils.fieldsConcat(getOutputFields(), functionFields), 

7 functionFields, 

8 new EachProcessor(inputFields, function))); 

9 


} 
O 形 参 function 为 Function 类 型 ， 其 输入 的 字段 名 由 inputFields 定 义 ，functionFields 表 示 
新 输出 的 字段 名 。 
a 逐 行 操作 将 创建 一 个 新 的 节点 ， 节 点 的 输出 列 为 父 节 点 的 输出 列 加 上 函数 新 产生 的 列 
functionFields。 
口 用 户 通常 会 实现 Function 接 口 ， 并 利用 each 操 作对 流 中 的 每 条 消息 进行 处 型 
口 EachProcessor 用 来 调用 输入 的 函数 function。 


21.5 流 的 分 区 操作 
流 的 分 区 操作 是 非常 关键 的 ， 它 对 应 于 Storm 中 的 消息 分 组 方式 。 在 Trident 中 ， 消 息 的 分 组 


Ht 


o 
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方式 是 通过 添加 分 区 市 点 来 完成 的 。 与 处 理 节 点 不 同 , 分 区 节点 只 用 来 反映 处 理 节 点 之 间 的 消息 
接收 方式 ， 并 不 对 应 于 实际 的 Spout 或 者 Bolt 节 点 。 
下 面 定 义 的 函数 都 与 创建 分 区 节点 有 关 ， 讨 论 如 下 : 


public Stream partitionBy(Fields fields) { 
projectionValidation(fields); 
return partition(Grouping.fields(fields.toList())); 


ublic Stream partition(CustomStreamGrouping partitioner) { 
return partition(Grouping.custom serialized(Utils.serialize(partitioner))); 


1 
2 
3 
4 
5 
6 
7j 
8 


9 public Stream partition(Grouping grouping) { 
10 if( node instanceof PartitionNode) ( 


11 return each(new Fields(), new TrueFilter()).partition(grouping); 

12 } else { 

13 return topology.addSourcedNode(this, new PartitionNode( node.streamId, name, 
getOutputFields(), grouping)); 

14 jJ 

15 } 

16 


17 public Stream shuffle() ( 
18 return partition(Grouping.shuffle(new NullStruct())); 


19 } 

20 

21 public Stream global() ( 

22 // use this instead of storm's built in one so that we can specify a 
singleemitbatchtopartition 

23 // without knowledge of storm's internals 

24 return partition(new GlobalGrouping()); 

25 } 

26 

27 public Stream batchGlobal() { 

28 // the first field is the batch id 

29 return partition(new IndexHashGrouping(0)); 

30 } 

31 public Stream broadcast() { 

32 return partition(Grouping.all(new NullStruct())); 

33 ] 

34 


35 public Stream identityPartition() { 
36 return partition(new IdentityGrouping()); 
37 } 


a 第 9~15 行 是 流 分 区 操作 的 具体 实现 ， 它 以 Thrift 类 型 的 分 组 类 型 Grouping 为 形 参 。 

口 如 果 当 前 节点 已 经 为 分 区 节点 , 它 首 先 利用 each 操 作 添 加 一 个 TrueFilter 方 点 , 然后 调用 

each 操 作 产 生 的 流 的 分 区 操作 来 添加 分 区 节点 ， 即 第 13 行 完成 了 一 个 分 区 节点 的 添加 。 

口 这 样 便 保证 了 在 有 向 图 中 没有 任何 两 个 分 区 节点 是 直接 相连 的 。 分 区 节点 是 用 来 创建 节 
点 组 的 分 割 节 点 ， 两 个 分 区 节点 直接 相连 是 没有 意义 的 。 

表 21-1 对 分 区 操作 的 类 型 进行 了 总 结 。 
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表 21-1 分 区 操作 类 型 


identityPartition() new IdentityGrouping() 等 同 分 区 操作 ， 分 区 前 后 Task 的 并 行 度 相 同 

broadcast() Grouping.all(new NullStruct()) 全 分 组 方式 , 原 节 点 的 消息 将 到 达 每 一 个 目标 节点 

batchalobal() new IndexHashGrouping(0) 类 似 于 域 分 组 方式 (Fields Grouping) ， 根 据 消息 
的 第 1 列 内容 选 择 目标 节点 

global() new GlobalGrouping() 全 局 分 组 (Global Grouping) 操作 ， 消 息 到 达 第 
1 个 目标 节点 

shuffle() Grouping.shuffle(new NullStruct()) ”等 概率 地 随机 选择 目标 节点 

partitionBy(Fields fields) Grouping. fields (fields.toList()) 域 分 组 , 根据 消息 中 选 定 列 的 内 容 的 哈 希 值 选择 
目标 节点 


O Trident 的 流 分 区 操作 对 底层 的 分 组 方式 进行 了 抽象 ， 并 实现 了 几 种 用 户 自 定义 的 分 组 方 
X, fef SECHS IS EDU 例如 用 groupBy 代 替 了 域 分 组 方式 等 。 

O 在 Trident 中 ,传输 消息 的 第 1 列 通常 为 事务 序号 。batchGlobal 操 作 会 根据 事务 序号 所 在 列 
进行 域 分 组 ， 使 得 相同 事务 序号 所 对 应 的 数据 可 以 到 达 同 一 个 节点 ， 这 对 于 连接 等 操作 
是 非常 重要 的 。 


21.6 流 的 单 聚集 器 聚集 操作 


分 区 上 聚集 操作 利用 输入 的 聚集 器 对 一 个 分 区 中 属于 同一 事务 的 所 有 消息 进行 聚集 。 通常 可 
以 首先 在 分 区 内 部 进行 聚集 得 到 局 部 聚集 结果 , 然后 在 此 基础 上 进行 全 局 聚集 ,和 ola n 结果 。 
这 部 分 操作 是 Trident 中 最 为 复杂 的 部 分 ， 相 关 代码 如 下 : 


al 


public Stream partitionAggregate(Fields inputFields, Aggregator agg, Fields functionFields) { 
projectionValidation(inputFields) ; 
return _topology.addSourcedNode(this, 
new ProcessorNode( topology.getUniqueStreamId(), 
name, 


functionFields, 
functionFields, 
new AggregateProcessor(inputFields, agg))); 
} 
口 partitionAggregate 操 作 创建 了 新 的 处 理 节 点 ， 内 含 AggregatepProcessor 类 型 的 Trident 
Processor, 


O 输入 的 Aggregator 由 AggregateProcessor 来 调用 执行 。 
口 inputFields 为 agg 的 输入 列 ， 新 创建 节点 的 输出 列 为 AggregatorProcessor 的 输出 列 ， 即 为 
functionFields ， 与 each 的 操作 不 同 ，partitionAggregate 并 不 保留 输入 列 。 


21.7 流 的 多 聚集 器 聚集 操作 377 


21.7 ” 流 的 多 聚集 器 聚集 操作 


Trident 中 支持 对 Tues 组 输入 消息 同时 运行 多 个 聚集 器 , AR RET RR e RRA AOR 
又 积 的 形式 发 送出 去 。 这 部 分 内 容 是 较为 复杂 的 。 


21.7.1 ChainedAggregatorDeclarer 


类 ChainedAggregatorDeclarer 用 来 声明 聚集 需 的 链表 。 
AggType 定 义 了 聚集 的 类 型 ， 如 下 所 示 : 
private static enum AggType { 

PARTITION, 


FULL, 
FULL COMBINE 


下 面 简要 介绍 各 个 成 员 的 含义 。 
口 PARTITION 表 示 在 某 个 分 区 上 进行 的 聚集 。 
O FULL 表 示 在 所 有 分 区 上 的 聚集 。 
口 FULL_COMBINE 表 示 在 所 有 分 区 上 的 合并 聚集 操作 。Trident 对 于 此 类 型 的 聚集 进行 了 优化 ,会 首 
先 执行 单独 分 区 上 的 聚集 ， 然 后 在 其 分 区 聚集 的 结果 上 进行 全 局 聚集 ， 以 达到 较 高 的 效率 。 
类 ChainedAggregatorDeclarer 中 的 很 多 方法 都 返回 了 this 指 针 ,， 这 使 得 用 户 可 以 通过 “.” 操 
作 符 来 构建 聚集 器 链 。 
类 Aggspec 用 来 描述 聚集 链 中 的 Aggregator ， 其 中 含有 输入 字段 名 inFields 、 输 出 字段 名 
outFields 以 及 聚集 器 agg， 其 定义 如 下 : 


private static class AggSpec { 
Fields inFields; 
Aggregator agg; 
Fields outFields; 


} 
首先 介绍 类 ChainedAggregatorDeclarer 的 成 员 变 量 ， 其 代码 如 下 : 


List<AggSpec> _aggs = new ArrayList<AggSpec>(); 

TAggregatableStream stream; 

AggType type = null; 

GlobalAggregationScheme _globalScheme; 

其 中 各 个 成 员 变量 的 含义 如 下 。 

口 _aggs 存 储 聚 集 链 中 的 聚集 占 。 

O _stream 表 示 这 些 聚 集 融 将 要 处 理 的 流 ， 可 以 为 基本 流 也 可 以 为 分 组 流 。 
Q type KR RRRA, 
口 _globalScheme 在 全 局 聚集 的 时 候 有 效 。 
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类 ChainedAggregatorDeclarer 的 成 员 变 量 globalScheme 为 GlobalAggregationScheme 类 型 ， 下 
面 介绍 该 类 型 如 下 : 
public interface GlobalAggregationScheme«S extends IAggregatableStream» { 
IAggregatableStream aggPartition(S stream); // how to partition for second stage of aggregation 
BatchToPartition singleEmitPartitioner(); // return null if it's not single emit 


} 

aggPartition 方 法 根据 输入 的 流产 生 新 流 ， 而 singleEmitpPartitioner 则 用 来 获得 BatchTo 
Parition 的 实现 。 目 前 该 接口 有 两 种 实现 ， 分 别 对 应 于 不 同 目 的 。 

类 BatchGlobalAggScheme 实 现 了 该 接口 ， 其 aggParition 方 法 会 根据 事务 序号 的 哈 希 值 对 消息 
进行 分 组 。singleEmitpPartitioner 为 IndexHashBatchToPartition 对 象 ， 该 对 象 则 根据 事务 序号 来 
选择 发 送 消息 的 节点 。 类 BatchGlobalAggScheme 的 定义 如 下 : 


static class BatchGlobalAggScheme implements GlobalAggregationScheme«Stream» ( 


@Override 

public IAggregatableStream aggPartition(Stream s) { 
return s.batchGlobal(); 

】 


@Override 
public BatchToPartition singleEmitPartitioner() { 
return new IndexHashBatchToPartition(); 


} 
} 


类 GlobalAggScheme 中 的 aggpPartition 采 用 流 的 全 局 分 组 方式 singleEmitPartitioner 为 
GlobalBatchToParition 对 象 ， 即 由 第 一 个 Task 发 送 消息 。 类 GlobalAggScheme 的 定义 如 下 : 


static class GlobalAggScheme implements GlobalAggregationScheme«Stream» { 


(QOverride 

public IAggregatableStream aggPartition(Stream s) { 
return s.global(); 

】 


@Override 

public BatchToPartition singleEmitPartitioner() { 
return new GlobalBatchToPartition(); 

} 


} 


口 BatchGlobalAggScheme 对 象 主要 被 用 于 流 对 象 的 aggregate 方 法 中 , 即 拥有 同样 事务 序号 的 

消息 可 以 到 达 同 一 个 节点 。 

口 GlobalAggScheme 对 象 主要 被 用 于 流 的 persistentAggregate 方 法 中 ， 表 示 是 全 局 的 聚集 操 
作 ， 并 将 聚集 结果 写 和 到 存储 对 象 中 。 

注意 GroupedStream 类 也 实现 了 接口 GlobalAggregationScheme， 相 关 代码 如 下 : 
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public IAggregatableStream aggPartition(GroupedStream s) { 
return new GroupedStream(s. stream.partitionBy( groupFields), groupFields); 
} 


O 其 aggPartition 方 法 的 实现 为 : 利用 _groupFields 添 加 一 个 新 的 分 区 节点 ， 并 据 此 构建 一 
个 新 的 分 组 流 。 
口 singleEmitpPartitioner 返 回 空 ， 表 示 其 不 需要 处 理 空 的 集合 。 


21.7.2 分 区 上 的 局 部 聚集 操作 


partitionAggregate 用 于 完成 分 区 上 的 聚集 操作 ， 该 方法 返回 了 一 个 ChainedpPartition 
AggregatorDeclarer 对 象 ， 表 明 用 户 可 以 继续 在 该 流 上 进行 其 他 聚集 操作 。 该 方法 的 代码 如 下 : 


1 public ChainedPartitionAggregatorDeclarer partitionAggregate(Fields inputFields, 
Aggregator agg, Fields functionFields) { 
2 _type = AggType.PARTITION; 
3 _aggs.add(new AggSpec(inputFields, agg, functionFields)); 
4 return this; 
5] 
6 
7 public ChainedPartitionAggregatorDeclarer partitionAggregate(Fields inputFields, 
CombinerAggregator agg, Fields functionFields) { 
8 initCombiner(inputFields, agg, functionFields); 
9 return partitionAggregate(functionFields, new CombinerAggregatorCombineImpl(agg), 
functionFields); 
10 } 
11 
12 public ChainedPartitionAggregatorDeclarer partitionAggregate(Fields inputFields, 
ReducerAggregator agg, Fields functionFields) { 
13 return partitionAggregate(inputFields, new ReducerAggregatorImpl(agg), functionFields); 
14 } 
15 
16 private void initCombiner(Fields inputFields, CombinerAggregator agg, Fields 
functionFields) ( 
17 stream - stream.each(inputFields, new CombinerAggregatorInitImpl(agg), functionFields); 
18 } 


a 第 1~5$ 行 添加 一 个 聚集 器 ， 同 时 指定 其 type 为 PARTITION 类 型 。 

口 第 7~10 行 将 输入 的 CombinerAggregator 适 配 成 为 Aggregator 类 型 , 需要 分 成 两 步 来 完成 该 操作 。 

m 第 一 步 ， 在 第 16~18 行 定义 的 ijnitCombiner 方 法 中 ， 通 过 当前 流 的 each 操 作 来 添加 一 个 
节点 ， 该 节点 用 来 调用 CombinerAggregator 的 init 方 法 。Trident 利 用 CombinerAggrega 
torInitImpl 类 对 agg 进 行 适 配 , 注意 _stream 变 量 被 更 新 为 了 each 节 点 所 对 应 的 流 , 这 也 
表明 接 下 来 的 操作 是 发 生 在 each 节 点 上 的 。 

wm 第 二 步 ， 调 用 CombinerAggregatorCompineImp1 将 Combiner 适 配 成 聚集 怖 。 


21.7.3 ”全 局 聚集 操作 
aggregate 方 法 对 输入 的 流 进行 全 局 聚集 操作 ， 其 输入 为 局 部 聚集 操作 的 结果 ， 其 返回 值 为 
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ChainedFullAggregatorDeclarer 类 型 ,表明 用 户 可 以 进一步 对 流 进行 聚集 操作 ， 进 而 构成 一 个 聚 
集 器 的 链 。 该 方法 的 代码 如 下 : 


1 public ChainedFullAggregatorDeclarer aggregate(Fields inputFields, Aggregator agg, 


2 
3 
4 
5 


23 
24 


} 


} 


Fields functionFields) { 
return aggregate(inputFields, agg, functionFields, false); 


private ChainedFullAggregatorDeclarer aggregate(Fields inputFields, Aggregator agg, 


Fields functionFields, boolean isCombiner) { 
if(isCombiner) { 
if(_type == null) { 
type = AggType.FULL COMBINE; 


} else { 
type = AggType. FULL; 


_aggs.add(new AggSpec(inputFields, agg, functionFields)); 
return this; 


public ChainedFullAggregatorDeclarer aggregate(Fields inputFields, 
CombinerAggregator agg, Fields functionFields) { 
initCombiner(inputFields, agg, functionFields) ; 
return aggregate(functionFields, new CombinerAggregatorCombineImp1 (agg) , 
functionFields, true); 


public ChainedFullAggregatorDeclarer aggregate(Fields inputFields, 
ReducerAggregator agg, Fields functionFields) { 
return aggregate(inputFields, new ReducerAggregatorImpl(agg), functionFields) ; 


} 


第 5~15 行 添加 全 局 的 聚集 器 ， 根 据 输入 的 isCombiner 方 法 来 判断 参数 agg 的 类 型 ， 依 此 为 对 
_type 进 行 赋值 , 经 过 适 配 后 agg 本 身 不 能 区 分 它 是 AggregatorReducer 或 者 为 CombinerReducer。 其 
他 方法 与 局 部 聚集 絮 类 似 ， 这 里 不 再 蒙 述 。 

最 后 来 看 其 核心 方法 chainEnd 的 实现 ， 它 是 全 局 聚集 生成 的 执行 计划 ， 其 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 
9 


public Stream chainEnd() { 


Fields[] inputFields - new Fields[ aggs.size()]; 
Aggregator[] aggs - new Aggregator[ aggs.size()]; 
int[] outSizes - new int[ aggs.size()]; 
List<String> allOutFields = new ArrayList<String>(); 
Set<String> allInFields = new HashSet«String»(); 
for(int i=0; i« aggs.size(); i++) { 

AggSpec spec = _aggs.get(i); 

Fields infields = spec.inFields; 

if(infields==null) infields = new Fields(); 

Fields outfields = spec.outFields; 

if(outfields==null) outfields = new Fields(); 


inputFields[i] = infields; 


15 
16 
17 
18 
19 
20 
21 


22 
23 
24 
25 
26 


27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 ] 


aggs[i] = spec.agg; 

outSizes[i] = outfields.size(); 
allOutFields.addAll(outfields.tolist()); 
allInFields.addAll(infields.tolist()); 


if(new HashSet(allOutFields).size() !- allOutFields.size()) { 
throw new IllegalArgumentException("Output fields for chained 
aggregators must be distinct: " + allOutFields.toString()); 


Fields inFields = new Fields(new ArrayList<String>(allInFields)); 

Fields outFields = new Fields(allOutFields); 

Aggregator combined - new ChainedAggregatorImpl(aggs, inputFields, new 
ComboList.Factory(outSizes)); 


if( type!-AggType.FULL) { 
stream - stream.partitionAggregate(inFields, combined, outFields); 
} 


if(_type!=AggType.PARTITION) { 
stream = globalScheme.aggPartition( stream); 
BatchToPartition singleEmit = globalScheme.singleEmitPartitioner(); 
Aggregator toAgg - combined; 
if(singleEmit!-null) { 
toAgg - new SingleEmitAggregator(combined, singleEmit); 


// this assumes that inFields and outFields are the same for combineragg 
// assumption also made above 
stream - stream.partitionAggregate(inFields, toAgg, outFields); 

} 


return stream.toStream(); 


THE 


该 方法 利用 ChainedAggregatorImp1 来 执行 ChainedAggregatorDeclarer 中 定义 的 聚集 链 aggs。 


口 第 2~25 行 主要 为 ChainedAggregatorImp1 的 实例 化 做 准备 ,同时 检查 aggs 中 是 否 有 同名 的 列 
(这 是 不 允许 的 )， 在 第 26 行 得 到 一 个 聚集 器 combined。 
a 第 28~41 行 根据 聚集 类 型 产生 聚集 计划 。 


m PARTITION: 只 有 第 28~30 行 的 partitionAggregate 方 法 被 执行 ， 该 方法 会 添加 一 个 处 理 


节点 ， 并 执行 局 部 聚集 操作 。 


m FULL: 只 有 第 31~41 行 的 partitionAggregate 被 执行 。 
m FULL COMBINE: 则 两 个 部 分 的 partitionAggregate 都 被 执行 ， 表 示 为 先 在 分 区 上 进行 局 


部 聚集 ， 然 后 再 在 分 区 的 结果 上 进一步 聚集 。 


a 第 32~37 行 用 来 实现 全 局 的 聚集 操作 。 根 据 对 _globalScheme 对 象 的 分 析 ， 阁 为 流 对 象 , 需 
要 处 理 集合 为 空 的 情况 ， 则 利用 SingleEmitAggregator 对 聚集 器 combined 进 行 包装 ; AA 
分 组 流 对 象 则 不 需要 进行 这 一 操作 。 


21.7.4 


含有 多 个 聚集 器 的 partitionAggregate 操 作 


类 ChainedAggregatorDeclarer 可 用 来 添加 多 个 聚集 器 ， 该 类 的 定义 如 下 : 
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1 public ChainedAggregatorDeclarer chainedAgg() { 

2 return new ChainedAggregatorDeclarer(this, new BatchGlobalAggScheme()); 

3g 

4 

5 public Stream partitionAggregate(Fields inputFields, CombinerAggregator agg, 
Fields functionFields) { 


6 projectionValidation(inputFields); 

7 return chainedAgg() 

8 .partitionAggregate(inputFields, agg, functionFields) 
9 .chainEnd(); 

10} 

11 


12 public Stream partitionAggregate(Fields inputFields, ReducerAggregator 
agg,Fields functionFields) { 

13 projectionValidation(inputFields) ; 

14 return chainedAgg() 


15 .partitionAggregate(inputFields, agg, functionFields) 
16 .chainEnd(); 
17 } 


O 第 1~3 行 定义 的 chainedAgg 方 法 用 来 获得 ChainedAggregatorDeclarer 对 象 ， 注 意 该 对 象 操 
作 的 流 为 当前 流 ，GlobalAggScheme 对 象 为 BatchGlobalAggSheme 对 和 象 。 

a 第 5~10 行 添加 一 个 CombinerAggregator 聚 集 器 ， 第 12~17 行 添加 一 个 ReducerAggregator 聚 
Seat, chainEnd 方 法 会 将 这 些 聚 集 带 统一 启动 。 

口 可 以 看 出 ， 目 前 的 partitionAggregate 方 法 中 只 存在 一 个 聚集 器 。 知 希望 含有 多 个 聚集 般 ， 

则 用 户 需 要 使 用 类 似 的 方法 调用 chainedAgg 来 添加 多 个 聚集 器 ， 最 后 再 调用 chainEnd 方 法 。 

O Trident 这 部 分 的 设计 过 于 复杂 。 


.8 流 的 聚集 操作 


aggregate 方 法 与 partitionAggregate 的 实现 基本 一 致 ， 它 代表 了 全 局 的 聚集 。 它 也 对 


ReducerAggregator 和 CombinerAggregator 进 行 了 适 配 , 这 里 不 再 过 多 讨论 。aggregate 方 法 的 实现 
代码 如 下 : 


public Stream aggregate(Fields inputFields, Aggregator agg, Fields functionFields) { 
projectionValidation(inputFields); 
return chainedAgg() 
.aggregate(inputFields, agg, functionFields) 
.chainEnd(); 
} 


public Stream aggregate(Fields inputFields, CombinerAggregator agg, Fields functionFields) { 
projectionValidation(inputFields) ; 
return chainedAgg() 
.aggregate(inputFields, agg, functionFields) 
.chainEnd(); 
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public Stream aggregate(ReducerAggregator agg, Fields functionFields) { 
return aggregate(null, agg, functionFields); 


} 


public Stream aggregate(Fields inputFields, ReducerAggregator agg, Fields functionFields) { 
projectionValidation(inputFields) ; 
return chainedAgg() 
.aggregate(inputFields, agg, functionFields) 


} 


.chainEnd(); 


21.9 流 的 分 区 写 入 操作 


partitionPersist 操 作用 于 将 一 个 分 区 的 数据 存储 到 对 象 中 ， 该 方法 返回 一 个 TridentState 
对 象 ， 用 户 可 以 对 该 对 象 执 行 查 询 操 作 ( 例如 DRPC )。partitionPersist 的 代码 如 下 : 


1 public TridentState partitionPersist(StateFactory stateFactory, 
Fields inputFields, StateUpdater updater, Fields functionFields) { 
2 return partitionPersist(new StateSpec(stateFactory), inputFields, updater, functionFields); 


3j 
4 


5 public TridentState partitionPersist(StateSpec stateSpec, Fields inputFields, 
StateUpdater updater, Fields functionFields) { 
projectionValidation(inputFields); 


String id - 


WE, 


name, 


functionFields, 
functionFields, 


6 
7  topology.getUniqueStateId(); 

8 ProcessorNode n - new ProcessorNode( topology.getUniqueStreamId(), 
9 

1 


new PartitionPersistProcessor(id, inputFields, updater)); 
13 n.committer - true; 
14 n.stateInfo - new NodeStateInfo(id, stateSpec); 
15 return topology.addSourcedStateNode(this, n); 


StateUpdater 类 型 


a 第 5~17 行 是 该 操作 的 主要 实现 ，StateSspec 类 型 的 stateSpec 对 象 用 来 帮助 创建 存储 State 


I 的 updater 对 象 用 来 对 该 state 对 和 象 进行 更 新 。 


a 第 6~12 行 创建 了 一 个 处 理 节点 ,该 节点 含有 PartitionPersistProcessor 对 象 ， 用 于 利用 
StateUpdater 更 新 State 对 象 的 数据 。 

a 第 14 行 节点 的 stateInfo 对 象 被 初始 化 。 在 声明 SubTopology 对 象 时 , 将 根据 stateInfo 对 象 
创建 State 对 象 。 
a 第 15 行 调用 addsourcedStateNode 方 法 创建 一 个 节点 。 该 节点 与 普通 节点 的 区 别 在 于 ， 


addSourcedStateNode 方 法 返回 了 TridentState 对 象 , 该 对 象 代 表 了 操作 的 终止 , 所 以 不 存 
在 子 节 点 。 第 2 行 利用 stateFactory 对 象 来 构建 statespec 对 象 ， 是 addSourcedStateNode 方 


法 的 一 


个 重 载 。 
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21.10 ”查询 操作 
查询 操作 并 非 属于 流 操作 的 一 部 分 ， 但 它 可 用 来 查询 流 写 人 的 存储 对 象 ， 相 关 代 码 如 下 : 


1 public Stream stateQuery(TridentState state, Fields inputFields, QueryFunction 
function, Fields functionFields) { 


2 projectionValidation(inputFields); 

3 String stateId - state. node.stateInfo.id; 

4 Node n = new ProcessorNode( topology.getUniqueStreamId(), 

5 name, 

6 TridentUtils.fieldsConcat(getOutputFields(), functionFields), 
7 functionFields, 

8 new StateQueryProcessor(stateId, inputFields, function)); 

9 topology. colocate.get(stateId).add(n); 

10 return topology.addSourcedNode(this, n); 

11 } 


口 第 4~8 行 创建 一 个 处 理 节 点 ,该 节点 中 含有 StateQueryProcessor, 因 此 可 用 来 查询 State 对 象 。 
口 第 9% 行 将 该 节点 放 和 人 _coloctate 对 象 的 映射 中 。 键 为 stateId， 值 为 对 同一 个 存储 对 象 进行 
操作 的 所 有 节点 , 在 Topology 执 行 优化 的 过 程 中 , 会 将 这 些 节 点 放 人 同一 个 Bolt 中 来 执行 。 


21.11 流 的 全 局 写 入 操作 


persistentAggreate 操 作 即 为 在 全 局 的 节点 上 执行 partitionPersist 操 作 ， 其 代码 如 下 : 


public TridentState persistentAggregate(StateSpec spec, Fields inputFields， 
ReducerAggregator agg, Fields functionFields) { 
projectionValidation(inputFields); 
return global().partitionPersist(spec, inputFields, new 
ReducerAggStateUpdater(agg), functionFields); 
} 


在 上 述 代码 中 , 我 们 首先 利用 global() 函数 创建 分 区 节点 ， 使 得 所 有 的 数据 都 汇集 到 一 个 节 
点 上 ， 然 后 在 该 节点 上 调用 partitionpPersist 方 法 进行 聚集 并 存储 。 


21.12 ” 流 的 操作 与 有 向 图 构建 
表 21-2 列 举 了 流 的 各 种 方法 与 构建 有 向 图 的 关系 ， 并 且 给 出 了 相关 类 。 
21-2 流 操作 与 有 向 图 构建 


操作 名 称 Bom JH X 类 
project 创建 处 理 节 点 ProjectedProcessor 
groupBy 不 创建 新 的 节点 返回 一 个 Groupedstream 对 象 
partitionBy 创建 分 区 节点 Fields Grouping 
each 创建 处 理 节点 EachProcessor 


操作 名 称 节 OR TH X 类 
partitionAggregate 创建 处 理 节点 ， 根 据 需 要 创建 分 区 节点 CombinerAggregatorCombineImpl 
CombinerAggregatorInitImpl 


= 


ReducerAggregatorImpl 
ChainedAggregatorImp1 
ChainedAggregatorDeclarer 
BatchGlobalAggScheme 
aggregate 创建 处 理 节 点 ， 根 据 需要 创建 分 区 节点 CombinerAggregatorCombineImpl 
CombinerAggregatorInitImpl 


ReducerAggregatorImpl 
ChainedAggregatorImp1 
ChainedAggregatorDeclarer 


BatchGlobalAggScheme 
partitoinPersist 创建 处 理 节 点 ReducerAggStateUpdater 
stateQuery 创建 处 理 节 点 StateQueryProcessor 
persistentAggregate 创建 分 区 节点 以 及 处 理 节 点 Global Grouping 


GlobalAggregationScheme 
21.13. 分 组 流 
当 流 进行 分 组 操作 时 , 将 会 产生 分 组 流 对 象 。 接 下 来 的 操作 都 是 在 利用 分 组 域 做 键 进行 分 组 
后 的 消息 集合 上 进行 的 ， 这 与 SQL 的 设计 相 类 似 。 分 组 流 中 的 操作 经 常 需 要 借助 分 区 节点 帮助 ， 


以 及 借助 在 分 组 内 消息 集合 上 聚集 操作 的 协助 。 学 习 这 个 类 的 时 候 可 以 对 比 基 本 流 的 实现 , 并 思 
考分 组 流 与 基本 流 是 如 何 互 相 转换 的 。 


21.13.1 成 员 变量 


GroupedStream 类 的 定义 如 下 所 示 : 


public class GroupedStream implements IAggregatableStream, GlobalAggregationScheme«GroupedStream» { 
Fields groupFields; 
Stream stream; 


} 

其 中 各 个 成 员 变 量 的 含义 如 下 。 

O _groupFields 表 示 用 于 进行 分 组 的 域 。 
Q _stream 为 基本 流 对 象 。 


21.13.2 ”了 逐 行 操 作 


分 组 流 上 的 each 操 作 将 通过 调用 基本 流 的 each 操 作 来 完成 ， 这 个 操作 将 继续 返回 分 组 流 。 由 
于 each 操 作 是 在 消息 层面 进行 处 理 而 不 需要 聚集 ， 所 以 分 组 流 的 each 操 作 与 基本 流 的 类 似 。 其 代 
ae: 
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public IAggregatableStream each(Fields inputFields, Function function, Fields functionFields) { 
Stream s = stream.each(inputFields, function, functionFields); 
return new GroupedStream(s,  groupFields); 


) 
21.13.3 “分 组 流 的 分 区 聚集 操作 


分 组 流 的 partitionAggregate 操 作 是 利用 GroupedAggregator 来 完成 的 。 该 聚集 顺 会 首先 调用 
_groupFields 对 输入 消息 进行 分 组 , 然后 在 分 组 后 的 集合 上 调用 聚集 需 agg, 该 操作 将 返回 一 个 分 
组 流 。 相 关 代码 如 下 : 


public IAggregatableStream partitionAggregate(Fields inputFields, Aggregator agg, 
Fields functionFields) { 
Aggregator groupedAgg = new GroupedAggregator(agg, groupFields, inputFields, function 
Fields.size()); 
Fields allInFields - TridentUtils.fieldsUnion( groupFields, inputFields); 
Fields allOutFields - TridentUtils.fieldsConcat( groupFields, functionFields); 
Stream s = stream.partitionAggregate(allInFields, groupedAgg, allOutFields); 
return new GroupedStream(s,  groupFields); 


) 
21.13.4 查询 操作 


stateQuery 操 作 首先 调用 流 的 分 区 操作 ， 其 输入 参数 为 _groupFields。 这 样 就 创建 了 域 分 区 
节点 , 随 着 数据 在 不 同 的 Bolt 节 点 之 间 传 输 ，_groupFields 值 相同 的 节点 将 到 达 相 同 的 目标 节点 。 
partitionBy 操 作 返 回 基本 流 对 象 ， 然 后 这 里 将 调用 基本 流 对 象 的 stateQuery 操 作 。 

分 组 流 的 stateQuery 操 作 返 回 基 本 流 对 象 ， 其 代码 如 下 : 


public Stream stateQuery(TridentState state, Fields inputFields, QueryFunction function, 
Fields functionFields) { 
return stream.partitionBy( groupFields) 
.stateQuery(state, 
inputFields, 
function, 
functionFields); 


) 
21.13.5 “聚集 操作 
分 组 流 上 aggregate 操 作 的 实现 较为 复杂 ， 相 关 代码 如 下 : 


1 public ChainedAggregatorDeclarer chainedAgg() { 

2 return new ChainedAggregatorDeclarer(this, this); 

3] 

4 

5 public Stream aggregate(Fields inputFields, Aggregator agg, Fields functionFields) { 
6 return new ChainedAggregatorDeclarer(this, this) 

7 .aggregate(inputFields, agg, functionFields) 

8 .chainEnd(); 


9 } 

10 

11 public IAggregatableStream aggPartition(GroupedStream s) { 

12 return new GroupedStream(s. stream.partitionBy( groupFields),  groupFields); 
13 } 


O 第 1~3 行 定义 了 chainedAgg 方 法 , 注意 ChainedAggregatorDeclarer 的 第 二 个 参数 传人 了 this 

指针 ， 且 分 组 流 也 实现 了 接口 GlobalAggregationSscheme， 所 以 可 以 这 样 调用 。 

OQ FÆ, fEChainedAggregatorDeclarer 的 chainEnd 方 法 中 将 调用 定义 在 第 11~13 行 的 
aggPartition 方 法 ， 该 方法 对 源 基本 流 调用 分 区 操作 ， 从 而 创建 新 的 分 区 节点 。 

摘抄 chainEnd 函 数 的 部 分 代码 如 下 : 


1 public Stream chainEnd() { 


2 

3 Aggregator combined = new ChainedAggregatorImpl(aggs, inputFields, new ComboList. 
Factory(outSizes)); 

4 

5 if( type!-AggType.FULL) { 

6 stream - stream.partitionAggregate(inFields, combined, outFields); 

7 

8 if( type!-AggType.PARTITION) ( 

9 stream - globalScheme.aggPartition( stream); 

10 BatchToPartition singleEmit = globalScheme.singleEmitPartitioner(); 

11 Aggregator toAgg - combined; 

12 if(singleEmit!-null) { 

13 toAgg - new SingleEmitAggregator(combined, singleEmit); 

14 

15 // this assumes that inFields and outFields are the same for combineragg 

16 // assumption also made above 

17 stream - stream.partitionAggregate(inFields, toAgg, outFields); 

18 } 

19 return stream.toStream(); 

20 } 


O 第 9 行 _stream 对 象 为 分 组 流 ， 它 含有 groupFields 进 行 分 区 的 节点 。 

O 由 于 第 12 行 的 singleEmit 为 空 ,所 以 将 调用 分 组 流 上 的 partitionAggregate 方 法 ( 第 17 行 )。 
口 第 19 行 调用 _stream.toStream 方 法 返回 分 组 流 中 的 基本 流 对 象 。 

O 该 操作 的 含义 是 : 首先 按照 groupedFields 对 输入 流 进行 重新 分 区 ,然后 在 每 个 分 区 上 调 
用 基于 分 组 的 聚集 算法 。 由 于 具有 相同 _groupedFields 值 的 消息 都 已 经 在 同一 个 节点 上 
了 ， 所 以 返回 的 将 是 流 对 象 而 不 是 分 组 流 对 象 。 


21.13.06 ” 写 入 操作 


persistentAggregate 操 作 是 基于 aggregate 操 作 来 完成 的 ， 其 代码 如 下 : 


public TridentState persistentAggregate(StateSpec spec, Fields inputFields, CombinerAggregator 
agg, Fields functionFields) { 
return aggregate(inputFields, agg, functionFields) 
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.partitionPersist(spec, 
TridentUtils.fieldsUnion( groupFields, functionFields), 
new MapCombinerAggStateUpdater(agg, _groupFields, functionFields), 
TridentUtils.fieldsConcat( groupFields, functionFields)); 
】 


O 根据 前 面 的 分 析 ， 分 组 流 上 的 aggregate 操 作 将 返回 已 经 按照 _groupFields 进 行 分 区 且 聚 
集 的 流 对 象 。 然 后 ， 调 用 流 对 象 的 partitionPersist 方 法 。 

口 利用 MapCombinerAggStateUpdater 来 对 已 根据 _groupFields 进 行 分 组 的 存储 数据 进行 更 
新 ， 其 State 对 象 为 MapState,， 键 为 _ groupFields， 值 为 groupFields 上 分 组 集合 的 聚集 结 
果 。 


21.14 ”利用 流 操作 来 构建 Topology 的 例子 


在 Trident 中 ， 用 户 通 过 流 的 操作 来 完成 Topology 的 构建 ，Trident 则 需要 将 用 户 的 代码 合理 地 
分 配 到 Storm 的 运行 节点 中 。Trident 进 行 了 较 好 的 抽象 ， 使 用 户 可 以 更 加 专注 于 代码 逻辑 。 但 这 
也 带 来 了 额外 的 复杂 性 ， 即 当 出 现 问题 时 ， 用 户 需 要 清楚 自己 代码 的 运行 和 部 署 过 程 。 

下 面 的 代码 来 自 于 StormStarter 项 目 中 关于 Trident 的 一 个 例子 , 这 部 分 代码 十 分 精炼 , 本 节 将 
分 析 下 面 的 代码 如 何 被 构建 成 为 Topology。 


1 TridentState wordCounts = 


2 topology.newStream("spouti", spout) 

3 .parallelismHint(16) 

4 .each(new Fields("sentence"), new Split(), new Fields("word")) 
5 .groupBy (new Fields("word")) 

6 .persistentAggregate(new MemoryMapState.Factory(), 

7 new Count(), new Fields("count")) 

8 .parallelismHint(16); 


a 第 2 行 调用 newStream, 将 产生 一 个 id 为 s1 的 流 ， 该 流 含有 一 个 Spout 节 点 。 为 便于 理解 ， 下 
面 我 们 列举 该 节点 在 运行 时 成 员 变量 的 值 。 
storm.trident.planner.SpoutNode[ 
spout-storm.trident.testing.FixedBatchSpout 
txId-spouti 
type-BATCH 
name-«null» 
allOutputFields-[sentence] 
streamId-s1 
creationIndex-1] 


a 第 3 行为 该 节点 设置 并 行 度 。 

a 第 4 行 的 each 操 作 将 会 产生 一 个 新 的 流 S2。 它 将 s1 作 为 输入 流 ， 构 建 了 一 条 从 s1 到 s2 的 有 
向 边 。 

a 第 5 行将 产生 一 个 分 组 流 ， 分 组 流 对 象 包含 两 个 成 员 变 量 。 一 个 是 _groupedFields ， 指 明 
按照 哪些 Fields 进 行 分 组 ,在 我 们 的 例子 中 为 word 列 。 男 一 个 是 _stream, 将 要 进行 分 组 的 
流 对 象 ， 在 我 们 的 例子 中 为 流 s2。 
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O 第 6 行将 对 分 组 后 的 流 进行 聚集 操作 ， 也 是 最 为 复杂 的 部 分 。 大 体 上 经 过 三 个 步骤 : 
m 在 每 个 分 区 上 进行 局 部 的 聚集 操作 ; 
mu 然后 在 单一 节点 上 在 对 局 部 聚集 的 结果 进行 聚集 ， 这 样 我 们 可 以 得 到 全 局 的 聚集 结果 ; 
mu 最 后 将 全 局 的 结果 存储 在 State 对 象 中 。 

首先 看 一 下 CombinerAggregator 接 口 ， 其 代码 如 下 : 


public interface CombinerAggregator«T» extends Serializable { 
T init(TridentTuple tuple); 
T combine(T vali, T val2); 
T zero(); 


} 


它 主 要 包含 3 个 成 员 方法 ，init 方 法 将 输入 的 Tuple 转 化 成 为 对 象 T，combine 方 法 将 对 输入 的 
两 个 T 对 象 进行 操作 并 产生 新 的 对 象 T，zeto 方 法 用 来 表示 默认 值 。 通 过 这 些 接口 方法 ，Trident 可 
以 构建 起 一 颗 层 级 的 树 状 结构 以 完成 最 终 的 聚集 操作 。 

接 下 来 我 们 来 看 一 下 Count 这 个 CombinerAggregator 的 实现 ， 其 代码 如 下 : 


public class Count implements CombinerAggregator<Long> { 
@Override 
public Long init(TridentTuple tuple) { 
return 1L; 
} 


@Override 

public Long combine(Long vali, Long val2) { 
return vali + val2; 

} 


@Override 
public Long zero() { 
return OL; 


} 

它 的 目标 是 分 布 式 地 计算 输入 消息 的 行 数 ， 于 是 在 init 方 法 中 返回 1 ， 在 combine 方 法 中 返回 
输入 的 两 个 临时 聚集 的 和 ， 在 zero 方 法 中 返回 0。 

例子 中 第 6~7 行 用 来 将 Count 应 用 在 节点 中 ， 以 分 布 式 地 完成 计算 。 其 中 , 我 们 需要 对 每 一 个 
输入 的 消息 调用 Count 的 init 方 法 ， 在 Trident 中 利用 EachProcessor 来 完成 这 项 工作 ， 在 Each 
Processor 中 将 调用 count 的 init 方 法 。 于 是 Trident 创 建 了 流 s3， 其 基本 信息 如 下 : 


storm.trident.planner.ProcessorNode [ 
committer=false 
processor-storm.trident.planner.processor.EachProcessor 
selfOutFields-[count] 
nodeId=3133ab19-17da-4d74-a9c2-a4f022406560 
name-«null» 
allOutputFields-[sentence, word, count] 
streamId-s3 
creationIndex-3 
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在 EachProcessor 中 将 调用 CombinerAggregatorInitImp1， 然 后 CombinerAggregatorInitImp1 将 
调用 Count 的 init 方 法 。 该 流 的 输出 为 [sentence, word, count]， 显 然 count 为 0。CombinerAggregator 
InitImpI 的 代码 如 下 : 


public class CombinerAggregatorInitImpl implements Function { 


CombinerAggregator agg; 
public CombinerAggregatorInitImpl(CombinerAggregator agg) { 
-8388 = 388; 


@Override 

public void execute(TridentTuple tuple, TridentCollector collector) { 
collector.emit(new Values(_agg.init(tuple))); 

} 


@Override 
public void prepare(Map conf, TridentOperationContext context) { 


} 


(QOverride 
public void cleanup() { 


} 


TEXT LY LZR, execute TIAA MHA IAA RAY agg.init(tuple), 并 将 结果 进行 输 
出 。 其 中 Fucntion 接 口 是 比 较 基 础 的 , 它 表 示 对 输入 的 消息 进行 处 理 , 并 通过 collector 将 其 输出 ， 
其 代码 如 下 : 


public interface Function extends EachOperation { 
void execute(TridentTuple tuple, TridentCollector collector); 
} 


接 下 来 ，Trident 需 要 对 已 经 初始 化 的 消息 进行 聚集 操作 。 因 为 是 在 分 组 后 的 流 上 进行 的 , 所 
以 所 有 的 聚集 操作 都 是 以 分 组 域 作 为 关键 字 的 , 即 表示 我 们 将 对 单词 进行 计数 ， 而 不 是 整个 句子 
进行 计数 。 基 本 上 具有 如 下 调用 骨 套 关系 : 


(1) storm. trident.planner.processor.AggregateProcessor 


(2) storm. trident.operation.impl.GroupedAggregator 

(3) storm.trident.operation.impl.ChainedAggregatorImpl 

(4) storm. trident.operation.impl.CombinerAggregatorCombineImpl 
(5) storm. trident.operation.builtin.Count 

O 在 4 的 aggregate 方 法 中 ， 将 调用 Count 的 combine 方 法 。 

口 3 可 以 包含 多 个 类 似 于 4 的 aggregate， 并 依次 分 别 执行 。 

a 2 将 在 分 组 好 的 消息 的 基础 上 执行 3。 

口 1 中 将 调用 2 的 aggregate 方 法 。 

这 些 操 作 被 封装 在 一 个 新 的 流 s4 中 ， 其 基本 信息 如 下 : 


21.14 利用 流 操作 来 构建 Topology 的 例子 391 


storm.trident.planner.ProcessorNode 
committer=false 
processor-storm.trident.planner.processor.AggregateProcessor 
selfOutFields-[word, count] 
name-«null» 
allOutputFields-[word, count] 
streamId-s4 
parallelismHint-«null» 
creationIndex=4 


] 


接 下 来 ，Trident 会 在 初步 聚集 的 节点 后 面 插 和 人 一 个 含有 实际 聚集 操作 的 节点 ， 该 节点 主要 包 
含 一 个 分 组 的 域 。 


storm. trident.planner.PartitionNode@46d8694[ 
name-«null» 
allOutputFields-[word, count] 
streamId-s4 
parallelismHint-«null» 
stateInfo-«null» 
creationIndex=5 


] 


注意 ， 其 streamId 为 4， 但 是 creationIndex 为 5， 表 示 其 为 一 个 新 的 流 ， 该 节点 会 导致 数 据 
从 初步 聚集 的 节点 发 送 到 一 个 单一 的 全 局 聚集 节点 ， 所 以 用 s4 作 为 StreamId 也 是 可 以 的 。 
然后 ，Trident 会 在 全 局 节点 上 运行 与 流 s4 上 非常 相近 的 操作 ， 只 是 不 需要 再 次 调用 init 方 法 
或 再 次 产生 一 个 新 的 节点 了 。 流 的 基本 信息 如 下 : BER 


storm.trident.planner.ProcessorNode 
committer-false 
processor-storm.trident.planner.processor.AggregateProcessor 
selfOutFields-[word, count] 
nodeId-6aa7a808-1627-4871-a8a9-4151148ef2b0 
name-«null» 
allOutputFields-[word, count] 
streamId-s5 
parallelismHint-«null» 
stateInfo-«null» 
creationIndex-6 


第 22 章 
Trident 流 的 交 Him Jr 


Trident 中 流 的 交互 操作 涉及 多 个 流 之 间 的 交互 ， 如 流 的 连接 或 合并 等 。 基 本 的 类 关系 如 图 
22-1 所 示 。 
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图 22-1 ”多 流 操 作 的 类 关系 


由 于 每 一 个 流 都 是 由 无 限 的 消息 构成 的 ，Trident 中 的 多 流 操作 仅 局 限于 某 一 个 事务 内 部 。 例 
用 户 要 进行 Streami 和 Stream 关 于 第 1 列 的 连接 操作 : 
在 多 Id=1 时 ，Streami 发 送 消息 <A, 1>, «A52»; 
在 txId=2 时 ，Streami 发 送 消息 <Al, 3>，<A> 4>; 
在 txId=1 时 ，Stream> 发 送 消 息 <A, 5», «A56»; 
在 txId=2 时 ，Streany 发 送 消 息 <Al, 7>, «A8». 
即 Streaml 和 Stream2 分 别 发 送出 去 4 条 消息 。 然 而 在 进行 连接 操作 时 ， 只 能 在 一 个 事务 内 部 进 
行 ， 事 务 之 间 不 能 进行 连接 ， 则 得 到 如 下 结 

txId=1H], <A}, 1 5>, <A,, 2, 6>; 

txId=2AY, «A,,3, 75, «A5,4,8», 

想 进 行 全 局 的 连接 操作 ， 用 户 需要 将 其 中 一 个 流 的 结果 存储 为 state 对 象 ， 然 后 让 另外 一 

mu 过 StateQuery 操 作 来 查询 第 一 个 流 的 结果 。 


22.1 基本 接口 


MultiReducer 接 口 主 要 用 于 对 多 个 流 进行 操作 。Trident 利 用 MultiReducerProcessor 来 执行 
MultiReducer ， 其 execute 方 法 传人 的 形 参 streamIndex 代 表 了 输入 的 消息 是 从 哪个 流 获得 的 。 接 


口 的 代码 如 下 : 


如 
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public interface MultiReducer<T> extends Serializable { 
void prepare(Map conf, TridentMultiReducerContext context) ; 
T init(TridentCollector collector); 
void execute(T state, int streamIndex, TridentTuple input, TridentCollector collector) ; 
void complete(T state, TridentCollector collector); 
void cleanup(); 


} 


而 GroupedMultiReducer 接 口中 execute 方 法 所 收 到 的 消息 ， 除 了 带 有 streamIndex 信 息 之 外 ， 
都 属于 同一 个 特定 分 组 ， 所 以 GroupedMultiReducer 主 要 用 作 连 接 操作 。 该 接口 的 实现 如 下 : 


public interface GroupedMultiReducer<T> extends Serializable { 
void prepare(Map conf, TridentMultiReducerContext context); 
T init(TridentCollector collector, TridentTuple group); 
void execute(T state, int streamIndex, TridentTuple group, TridentTuple input, TridentCollector 
collector); 
void complete(T state, TridentTuple group, TridentCollector collector); 
void cleanup(); 


22.2 JoinerMultiReducer 


Joinstate 结 构 是 ]JoinerMultiReducer 进 行 连 接 的 数据 结构 。 其 中 , sides 存 储 了 每 个 流 已 经 收 
到 的 消息 ，numSidesReceived 表 示 已 经 从 哪些 流 收 到 了 消息 ，group 表 示 进 行 连接 的 值 ，indices 
表示 sides 中 元 素 的 下 标 。Joinstate 的 代码 如 下 : 2 


public static class JoinState { 
List<List>[] sides; 
int numSidesReceived = 
int[] indices; 
TridentTuple group; 


public JoinState(int numSides, TridentTuple group) { 
sides = new List[numSides]; 
indices = new int[numSides]; 
this.group = group; 
for(int i=0; i«numSides; i++) { 
sides[i] = new ArrayList<List>(); 


} 
} 
JoinerMultiReducer 类 用 于 完成 多 个 流 的 连接 操作 。 
22.2.1 成 员 变 量 及 构造 函数 
首先 分 析 ]JoinerMultiReducer 所 包含 的 数据 和 构造 方法 ， 相 关 代码 如 下 : 
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public class JoinerMultiReducer 


1 

2 

3 List«JoinType» types; 

4 List«Fields»  sideFields; 

5 int numGroupFields; 

6 ComboList.Factory factory; 
7 
8 
9 


implements GroupedMultiReducer«JoinState» { 


public JoinerMultiReducer(List«JoinType» types, int numGroupFields, List«Fields» sides) { 


10 types - types; 

11  SideFields - sides; 

12  numGroupFields - numGroupFields; 

13 

14 public void prepare(Map conf, TridentMultiReducerContext context) { 
15 int[] sizes = new int[ sideFields.size() + 1]; 
16 sizes[0] = numGroupFields; 

17 for(int i-0; i« sideFields.size(); i++) { 

18 sizes[i+1] = sideFields.get(i).size(); 

19 } 

20 _factory = new ComboList.Factory(sizes); 

21 } 

22 } 


_types 为 连接 类 型 ， 其 定义 如 下 : 


public enum JoinType { 
INNER, 
OUTER; 

} 


O 该 类 型 反映 了 某 一 个 输入 流 在 没有 消息 时 该 如 何 进 行 处 理 。 若 为 OUTER 类 型 ， 将 用 
List<null> 来 表示 该 流 的 消息 ; 若 为 INNER 类 型 且 没 有 消息 ， 则 整个 连接 将 没有 输出 。 在 
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流 的 列 数 。 


接 的 流 的 个 数 。 


E， 即 _types 的 数目 与 进行 连接 的 流 的 数目 相同 。 
口 _sideFields 是 每 一 个 参加 连接 的 流 的 模式 。 
口 _numGroupFields 为 连接 的 键 的 数目 。 

口 _factory 用 来 产生 最 终 的 输出 ， 输 出 的 列 数 为 _ numGroupFields 加 上 _sideFields 中 每 一 个 


口 从 第 14~21 行 定义 的 prepare 方 法 可 以 看 出 ，_factory 共 有 N+1 部 分 构成 ， 其 中 NN 为 参与 连 


init 函 数 根 据 分 组 域 构 建 Joinstate 对 象 ， 消 息 group 为 连接 的 连接 键 ， 它 是 各 个 流 的 列 中 相 


同 的 部 分 。 函 数 init 的 代码 如 下 : 


public JoinState init(TridentCollector collector, TridentTuple group) { 
return new JoinState( types.size(), group); 


} 
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22.2.2 execute 


Trident 保 证 JoinerMultiReducer 收 到 的 消息 都 属于 同一 个 分 组 , 即 在 exeucte 方 法 中 形 参 group 
的 值 与 init 方 法 中 形 参 group 的 值 相同 。 也 就 是 说 , execute 方 法 收 到 的 消息 都 是 满足 连接 条 件 的 ， 
理解 这 点 很 重要 。execute 方 法 完成 了 内 连接 ( InnerJoin )， 其 代码 如 下 : 


1 public void execute(JoinState state, int streamIndex, TridentTuple group, TridentTuple input, 
TridentCollector collector) { 
2 //TODO: do the inner join incrementally, emitting the cross join with this tuple, against 
all other sides 


3 //TODO: only do cross join if at least one tuple in each side 

4 List«List» side - state.sides[streamIndex]; 

5 if(side.isEmpty()) ( 

6 state.numSidesReceived++; 

7 } 

8 

9 side.add(input) ; 

10 if(state.numSidesReceived == state.sides.length) { 

11 emitCrossJoin(state, collector, streamIndex, input); 

12 } 

13} 

O 第 4 行 与 第 9% 行 根据 streamIndex 找 到 Joinstate 对 象 中 用 于 存储 该 流 消 息 的 列表 ， 然 后 将 该 
消息 存储 。 


a 第 $~7 行 ， 若 第 一 次 从 某 流 收 到 消息 ， 则 更 新 numsidesReceived 变 量 。 

口 第 10 行 ， 若 已 经 从 参与 连接 的 流 都 收 到 了 消息 ， 则 已 经 可 以 进行 连接 了 。 接 下 来 ,调用 
emitCrossJoin 将 连接 上 的 消息 发 送出 去 ， 这 种 递增 地 进行 内 连接 的 方法 是 算法 的 核心 。 

下 面 来 看 emitCrossJoin 的 实现 ， 其 代码 如 下 : 


1 private void emitCrossJoin(JoinState state, TridentCollector collector, int overrideIndex, 
ridentTuple overrideTuple) ( 


2 List«List»[] sides - state.sides; 

3 int[] indices = state.indices; 

4 for(int i=0; i«indices.length; i++) { 

5 indices[i] = 0; 

6 } 

7 

8 boolean keepGoing = true; 

9 //emit cross-join of all emitted tuples 

10 while(keepGoing) { 

11 List[] combined = new List[sides.length+1]; 
12 combined[0] = state.group; 

13 for(int i=0; i«sides.length; i++) { 

14 if(i--overrideIndex) { 

15 combined[i+1] = overrideTuple; 

16 } else { 

17 combined[i+1] = sides[i].get(indices[i]); 
18 } 
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20 collector.emit( factory.create(combined)); 
21 keepGoing - increment(sides, indices, indices.length - 1, overrideIndex); 


26 //return false if can't increment anymore 
27 //TODO: DRY this code up with what's in ChainedAggregatorImpl 
28 private boolean increment(List[] lengths, int[] indices, int j, int overrideIndex) { 


29 if(j==-1) return false; 

30 if(je-overrideIndex) { 

31 return increment(lengths, indices, j-1, overrideIndex); 
32 

33 indices[j]++; 

34 if(indices[j] >= lengths[j].size()) { 

35 indices[j] = 0; 

36 return increment(lengths, indices, j-1, overrideIndex) ; 
37 } 

38 return true; 

39 } 


口 indices 为 要 发 送 的 消息 在 sides 中 的 下 标 ， 算 法 中 通过 不 断 更 新 下 标 数组 indices 来 完成 
XF, 
O 第 3~6 行 初始 化 indices 数 据 ， 使 其 指向 sides 中 第 0 条 消息 。 算 法 的 基本 思想 是 : 固定 
overrideIndex 对 应 的 流 ， 并 且 遍 历 其 他 流 中 已 有 的 消息 ，overrideIndex 所 在 的 流 的 消息 
固定 为 overrideTuple， 而 其 他 流 的 消息 则 根据 下 标 得 到 。 
例如 ，3 个 流 进行 连接 ，S1 目 前 的 消息 为 <A>, S$, 为 <>, S3 的 消息 为 <C, D>, 
(1) 若 收 到 $: 的 消息 B， 此 时 收 到 了 3 个 流 的 消息 ， 可 以 进行 连接 。 
消息 数组 为 : 
S1:<A>, S2:<B>, S3:<C, D>. 
MAAN: 
<A, B, C>, <A, B, D», 
(2) 若 接 下 来 收 到 S$, 的 消息 E， 消 息 数组 为 : 
S1:<A>, S2:<B, E>, S3:<C, D>. 
则 输出 如 下 的 消息 : 
<A, E, C», <A, E, D>, 
(3) 若 接 着 收 到 S| 的 消息 F， 消 息 数组 为 : 
Si1:<A, F>, S2:<B, E>, 83:<C, D», 
偷 出 的 消息 为 : 
«F, B, C», <F, B, D», «F, E, C», «F, E, D», 
最 终 输 出 的 消息 为 : 
«A, B, C», «A, B, D»,«A, E, C», «A, E, D>,<E, B, C», «F, B, D>, «F, E, C», «F, E, D> 。 这 与 
收 到 所 有 消息 之 后 再 进行 又 积 的 效果 是 相同 的 ， 但 实现 了 在 每 次 收 到 新 的 消息 时 ， 就 立 
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刻 将 满足 连接 条 件 的 消息 发 送出 去 的 效果 。 
22.2.3 complete75;A 
由 于 execute 方 法 已 经 完成 了 内 连接 ，complete 方 法 则 用 来 完成 外 连接 操作 ， 相 关 代 码 如 下 : 


1 public void complete(JoinState state, TridentTuple group, TridentCollector collector) { 
2 List«List»[] sides - state.sides; 

3 boolean wasEmpty - state.numSidesReceived « sides.length; 

4 for(int i=0; i«sides.length; i++) { 

5 if(sides[i].isEmpty() 8& _types.get(i) == JoinType.OUTER) { 

6 state.numSidesReceivedt+; 

7 sides[i].add(makeNulllist( sideFields.get(i).size())); 

8 


} 
9 
10 if(wasEmpty && state.numSidesReceived == sides.length) { 
11 emitCrossJoin(state, collector, -1, null); 
12 } 
13 } 
14 


15 @Override 
16 public void cleanup() { 


17 } 

18 

19 private List<Object> makeNullList(int size) { 
20 List<Object> ret = new Arraylist(size); 
21 for(int i-0; i«size; i++) { 

22 ret.add(null); 

23 

24 return ret; 

25 } 


口 第 3 行 的 wasEmpty 变 量 是 重要 的 。 若 它 为 真 ， 则 表示 从 各 个 流 都 收 到 了 消息 并 且 完 成 了 内 
连接 ， 则 complte 方 法 不 需要 再 做 任何 操作 。 若 wasEmpty 为 假 ， 则 表明 没有 从 某 些 源流 收 
到 消息 ， 内 连接 没有 完成 。 

口 第 4~9% 行 判断 每 一 个 源流 的 连接 类 型 ， 若 为 OUTER 类 型 ， 则 调用 makeNul1List 来 补充 一 条 空 

的 消息 。 

a 第 10~12 行 ， 若 经 过 添加 空 消息 ， 使 得 所 有 流 都 有 了 对 应 的 消息 ， 则 调用 emitCrossJoin 
来 完成 叉 积 并 发 送 结 果 。 注 意 ，overrideIndex 、overTideTuple 分 别传 人 了 - 1 和 空 dB 
将 遍历 所 有 流 中 的 所 有 消息 。 


22.3 GroupedMultiReducerExecutor 


JoinerMultiReducer 假 定 收 到 的 消息 均 是 满足 连接 条 件 的 ， 即 分 组 域 group 列 对 应 的 值 均 相 
同 ，Trident 通 过 GroupedMultiReducerExecutor 来 实现 这 一 点 。 这 个 类 的 代码 如 下 : 
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1 public class GroupedMultiReducerExecutor implements MultiReducer«Map«TridentTuple, Object>> { 
2 GroupedMultiReducer _reducer; 

3 List<Fields> _groupFields; 

4 List<Fields> _inputFields; 

5 List<ProjectionFactory> _groupFactories = new ArrayList<ProjectionFactory>(); 

6 

7 

8 


List«ProjectionFactory» _inputFactories = new ArrayList<ProjectionFactory>(); 


public GroupedMultiReducerExecutor(GroupedMultiReducer reducer, List<Fields> groupFields, 
List<Fields> inputFields) { 


9 if(inputFields.size()!-groupFields.size()) { 

10 throw new IllegalArgumentException("Multireducer groupFields and inputFields must 
be the same size"); 

11 } 

12 _groupFields = groupFields; 

13 _inputFields = inputFields; 

14 _reducer = reducer; 

15 } 

16 

17 @Override 

18 public void prepare(Map conf, TridentMultiReducerContext context) { 

19 for(int i=0; i« groupFields.size(); i++) { 

20 _groupFactories.add(context.makeProjectionFactory(i, _groupFields.get(i))); 

21 _inputFactories.add(context.makeProjectionFactory(i, _inputFields.get(i))); 

22 } 

23 _reducer.prepare(conf, new TridentMultiReducerContext((List) _inputFactories)); 

24 } 

25 

26 (QOverride 

27 public Map«TridentTuple, Object» init(TridentCollector collector) { 

28 return new HashMap(); 

29 } 

30 

31 @Override 


32 public void execute(Map<TridentTuple, Object> state, int streamIndex, TridentTuple full, 
TridentCollector collector) { 


33 ProjectionFactory groupFactory = _groupFactories.get(streamIndex) ; 
34 ProjectionFactory inputFactory = _inputFactories.get(streamIndex) ; 
35 

36 TridentTuple group = groupFactory.create(full) ; 

37 TridentTuple input = inputFactory.create(full); 

38 

39 Object curr; 

40 if(!state.containsKey(group)) { 

41 curr = _reducer.init(collector, group); 

42 state.put(group, curr); 

43 } else { 

44 curr = state.get(group) ; 

45 } 

46  reducer.execute(curr, streamIndex, group, input, collector); 

41 } 

48 


49 @Override 
50 public void complete(Map<TridentTuple, Object> state, TridentCollector collector) { 
51 for(Map.Entry e: state.entrySet()) { 
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52 TridentTuple group - (TridentTuple) e.getKey(); 
53 Object val - e.getValue(); 

54  reducer.complete(val, group, collector); 

55 } 

56 } 

57 } 


a 从 第 1 行 可 以 看 出 进行 聚集 的 数据 结构 为 Map<TridentTuple，0bject> 类 型 ， 其 中 键 为 通过 
分 组 列 创建 的 消息 ， 即 连接 的 键 ， 值 为 0bject 类 型 ， 在 JoinerMultiReducer 中 为 JoinState 
类 型 。 其 成 员 变量 和 构造 函数 较为 简单 ， 这 里 不 再 讨论 。 

口 第 27~29 行 的 init 方 法 中 ， 新 建 了 一 个 哈 希 值 用 来 存储 每 个 分 组 。 

口 第 32~47 行 实现 execute 方 法 。 第 33~37 行 根据 streamIndex 获 得 用 于 创建 输入 消息 和 分 组 消息 

的 工厂 类 ， 并 创建 出 分 组 消息 group 和 输入 消息 input。group 为 连接 的 键 ，input 为 其 他 列 。 

口 第 40~43 行 获得 连接 分 组 列 所 对 应 的 数据 。 大 为 第 一 次 连接 到 某 分 组 的 消息 ， 则 调用 
_reducer.init(collector, group) 进行 创建 。 对 于 JoinerMultiReducer ， 则 创建 一 个 
JoinState 对 象 。 

口 第 46 行 调用 _reducer 的 execute 方 法 。JoinerMultiReducer 的 exeute 方 法 则 将 进行 内 连接 。 

口 第 50~56 行 对 每 一 个 连接 键 所 在 的 消息 组 ， 调 用 _recuder 的 complete 方 法 来 完成 外 连接 ， 
当然 这 里 也 要 首先 根据 JOIN 的 类 型 来 判断 是 否 补充 空 消息 。 


22.4 MultiReducerProcessor 


MultiReducerProcessor 用 来 执行 MultiReducer > MultiReducerProcessor 继承 FA Trident 
Processor, 它 可 以 被 放置 在 Trident 的 处 理 节 点 中 执行 .下 面 我 们 来 看 一 下 MultiReducer Processor 
类 的 实现 代码 : 


1 public class MultiReducerProcessor implements TridentProcessor { 
2 MultiReducer reducer; 

3 TridentContext context; 

4 Map«String, Integer» _streamToIndex; 

5 List«Fields» _projectFields; 

6 ProjectionFactory[] _projectionFactories; 

7 FreshCollector collector; 

8 

9 public MultiReducerProcessor(List«Fields» inputFields, MultiReducer reducer) { 
10  reducer - reducer; 

11 _projectFields = inputFields; 

12 } 

13 


14 @Override 
15 public void prepare(Map conf, TopologyContext context, TridentContext tridentContext) { 


16 List<Factory> parents = tridentContext.getParentTupleFactories(); 
17 _context = tridentContext; 

18 _streamToIndex = new HashMap<String, Integer>(); 

19 List<String> parentStreams = tridentContext.getParentStreams(); 


20 for(int i=0; i«parentStreams.size(); i++) { 
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21 _streamToIndex.put(parentStreams.get(i), i); 
22 } 
23 _projectionFactories = new ProjectionFactory[ projectFields.size()]; 
24 for(int i-0; i« projectFields.size(); i++) { 
25 _projectionFactories[i] = new ProjectionFactory(parents.get(i), projectFields.get(i)); 
26 
27 collector - new FreshCollector(tridentContext); 
28  reducer.prepare(conf, new TridentMultiReducerContext((List) Arrays.asList 
( projectionFactories))); 
29 } 
30 
31 (QOverride 
32 public void cleanup() { 
33 _reducer.cleanup(); 
34 } 
35 
36 @Override 
37 public void startBatch(ProcessorContext processorContext) { 
38 _collector.setContext (processorContext) ; 
39 processorContext.state[ context.getStateIndex()] = _reducer.init(_collector) ; 
40 } 
41 
42 (QOverride 
43 public void execute(ProcessorContext processorContext, String streamId, TridentTuple tuple) { 
44 . collector.setContext(processorContext); 
45 int i- streamToIndex.get(streamId); 
46  reducer.execute(processorContext.state[ context.getStateIndex()], i, 
_projectionFactories[i].create(tuple), collector); 
47 } 
48 
49 @Override 
50 public void finishBatch(ProcessorContext processorContext) { 
51 _collector.setContext (processorContext) ; 
52  reducer.complete(processorContext.state[ context.getStateIndex()], collector); 
53 } 
54 


55 @Override 

56 public Factory getOutputFactory() { 

57 return collector. getOutputFactory(); 

9) 

理解 这 个 类 的 重点 在 于 看 它 是 如 何 适 配 MultiReducer 接 口 的 ， 即 何 时 去 调用 MultiReducer 中 
的 各 个 方法 。 下 面 简要 介绍 这 个 类 中 的 成 员 变量 和 方法 。 
口 _streamToIndex 存 储 了 从 流 名 字 到 流 编号 的 映射 关系 ， 编 号 从 0 开始 。 在 MultiReducer 的 
execute 方 法 中 需要 传人 streamIndex 形 人 参 。 
Q _projectFields 和 ._projectionFactories 用 来 根据 输入 的 消息 创建 连接 要 处 理 的 消息 。 
口 第 15~29 行 实现 prepare 方 法 。 通 过 TridentContext 获 得 该 节点 的 父 节 点 所 对 应 的 流 ， 并 对 这 
些 流 执行 连接 操作 。prepare 方 法 中 对 这 些 流 进行 了 编号 ， 并 调用 _reducer 的 prepare 方 法 。 
口 startBatch 方 法 对 该 Processor 的 数据 进行 了 初始 化 。 这 里 调用 了 _reducer 的 init 方 法 获得 ， 
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22. 


对 于 GroupedMultiReducerExecutory 和 JoinerMultiReducer 实 现 来 讲 ，init 方 法 返回 了 
HashMap«TridentTuple, JoinState»X]Z&. 

O 第 43~47 行 的 execute 方 法 会 根据 输入 消息 的 流 号 获得 流 的 编号 ， 并 调用 reducer H 

execute 方 法 。 类 似 地 ，finishBatch 方 法 中 会 调用 reducer 的 complete 方 法 。 

口 MultiReducerProcessor 的 输入 要 保证 具有 相同 连接 分 组 列 值 的 消息 都 到 达 相 同 的 节点 ， 
这 是 通过 分 区 节点 来 完成 的 。 


5 连接 操作 
Join 操 作 主要 由 下 面 4 个 函数 来 完成 ， 它 们 的 代码 如 下 ; 


1 public Stream join(List<Stream> streams, List<Fields> joinFields, Fields outFields, 
List<JoinType> mixed) { 


2 return multiReduce(strippedInputFields(streams, joinFields), 

3 groupedStreams(streams, joinFields), 

4 newJoinerMultiReducer(mixed, joinFields.get(0).size(), 

strippedInputFields(streams, joinFields)), 

5 outFields); 

6 } 

7 

8 private static List<GroupedStream> groupedStreams(List<Stream> streams, 
List<Fields> joinFields) { 

9 List«GroupedStream» ret = new ArrayList<GroupedStream>() ; 

10 for(int i-0; i«streams.size(); i++) { 

11 ret.add(streams.get(i).groupBy(joinFields.get(i))); 

12 } 

13 return ret; 

14 } 

15 


16 public Stream multiReduce(List<Fields> inputFields, List<GroupedStream> groupedStreams, 
GroupedMultiReducer function, Fields outputFields) { 
17 List<Fields> fullInputFields = new ArrayList<Fields>(); 


18 List<Stream> streams = new ArrayList<Stream>(); 

19 List<Fields> fullGroupFields = new ArrayList<Fields>(); 

20 for(int i=0; i«groupedStreams.size(); i++) { 

21 GroupedStream gs = groupedStreams.get(i); 

22 Fields groupFields = gs.getGroupFields(); 

23 fullGroupFields.add(groupFields); 

24 streams.add(gs.toStream().partitionBy(groupFields)); 

25 fullInputFields.add(TridentUtils.fieldsUnion(groupFields, inputFields.get(i))); 

26 

27 } 

28 return multiReduce(fullInputFields, streams, new GroupedMultiReducerExecutor(function, 
fullGroupFields, inputFields), outputFields); 

29 } 

30 


31 public Stream multiReduce(List<Fields> inputFields, List«Stream» streams, MultiReducer 
function, Fields outputFields) ( 

32 List<String> names = new ArrayList<String>(); 

33 for(Stream s: streams) { 
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34 if(s. name!-null) { 

35 names.add(s. name); 

36 } 

37 } 

38 Node n = new ProcessorNode(getUniqueStreamId(), Utils.join(names, "-"), outputFields, 
outputFields, new MultiReducerProcessor(inputFields, function)); 

39 return addSourcedNode(streams, n); 

40 } 


O 第 8~14 行 ，groupedSstreams 函 数 将 输入 的 流转 化 为 分 组 流 。 

a 第 11 行 通过 调用 流 的 groupBy 操 作 来 完成 向 分 组 流 的 转化 过 程 ， 分 组 域 为 进行 连接 操作 的 

连接 域 。 

口 第 1~6 行 定义 连接 操作 。strippedInputFie1d 函 数 用 来 将 输入 消息 中 进行 连接 的 列 去 除 。 
groupedStreams 孙 数 将 输入 的 流转 化 为 分 组 流 。 连 接 操作 通过 调用 第 16 行 的 multiReduce 
操作 来 完成 ， 实 际 进行 连接 的 对 象 为 JoinerMultiReducer。 

a 第 16~29 行 为 multiReduce 操 作 在 分 组 流 上 的 版 本 。 第 17~27 行 准备 输入 的 流 等 ， 第 24 行 调 
用 Groupedstream 的 partitionBy 操 作 创 建新 的 流 对 象 。 此 处 将 添加 分 区 节点 ， 具 有 相同 
groupFields 值 的 消息 将 到 达 同 一 个 节点 上 去 。 然 后 调用 第 31~40 行 定义 的 multiReduce 方 
法 ， 利 用 GroupedMultiReducerExecutor 对 JoinerMultiReducer 进 行 封 装 。 

口 第 31~40 行 为 multiReduce 操 作对 应 于 基本 流 的 版 本 ， 它 含有 一 个 处 理 节 点 ， 该 节点 使 用 

MultiReducerProcessor 来 完成 操作 。 

口 第 39 行 ，addSourcedNode 函 数 将 流 添 加 到 节点 an 的 边 ，streams 为 所 有 要 进行 操作 的 流 。 

为 了 便于 理解 ， 现 将 连接 操作 的 实现 过 程 绘制 成 图 ， 如 图 22-2 所 示 ， 并 给 出 步骤 归纳 。 
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u 要 进行 连接 的 流通 过 groupBy 变 为 分 组 流 ; 
m 通过 调用 partitionBy 添 加 分 区 节点 ; 
m 在 分 区 节点 之 后 添加 处 理 节 点 ， 该 处 理 节 点 完成 对 流 的 连接 操作 。 


22.6 RAHE 


merge 操 作 将 输入 的 各 个 流 的 消息 合并 在 一 起 。 各 个 流 的 消息 格式 需要 保持 统一 。merge 操 作 
需要 分 区 节点 的 协助 。 
merge 操 作 同 样 需 调用 multiReduce 来 完成 实现 ， 它 采用 了 IdentityMultiReducer 对 象 。merge 
操作 的 代码 如 下 : 


public Stream merge(Fields outputFields, List<Stream> streams) { 
return multiReduce(streams, new IdentityMultiReducer(), outputFields); 
} 


IdentityMultiReducer 的 实现 是 简单 的 ， 它 只 是 将 收 到 的 消息 发 送 了 出 去 ， 其 代码 如 下 : 


/ 


public class IdentityMultiReducer implements MultiReducer { 
@Override 
public void prepare(Map conf, TridentMultiReducerContext context) { 
} 
@Override 
public Object init(TridentCollector collector) { 


return null; 
} 


@Override 

public void execute(Object state, int streamIndex, TridentTuple input, TridentCollector collector) { 
collector.emit (input) ; 

} 


@Override 

public void complete(Object state, TridentCollector collector) { 
} 

@Override 

public void cleanup() { 

} 
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SubTopologyBolt 类 型 为 Trident 中 运行 的 基本 单位 ， 但 它 并 不 是 真正 的 Bolt 节 点 ，Trident 会 利 
用 TridentBoltExecutor 对 SubTopologyBolt 进 行 接 口 适 配 。TridentBoltExecutor 继 承 自 IRichBolt 
接口 ， 是 Trident 中 真正 运行 的 Bolt 节 点 。 它 提供 了 类 似 于 协调 Bolt ( CoordinatedBolt ) 节点 的 功 
能 ， 通 过 发 送 协调 消息 来 对 各 个 节点 进行 同步 。 

SubTopologyBolt 主 要 用 于 对 TridentpProcessor 的 执行 进行 抽象 。 本 章 将 讨论 SubTopologyBolt 
和 TridentBoltExecutor 的 实现 。 


23.1 SubTopologyBolt 


Trident 可 以 把 一 些 运算 放 在 同一 个 Bolt 中 来 执行 ， 这 个 Bolt 的 类 型 就 是 SubTopologyBolt。 它 
是 Trident 中 的 基本 执行 单位 。 本 节 对 SubTopologyBolt 进 行 详细 分 析 。 


23.1.1 输入 准备 


InitialReceiver 类 用 于 为 SubTopologyBolt 准 备 输入 ， 其 实现 代码 如 下 : 


1 protected class InitialReceiver { 

2 List«TridentProcessor» receivers = new Arraylist(); 

3 RootFactory factory; 

4 ProjectionFactory project; 

5 String stream; 

6 

7 public InitialReceiver(String stream, Fields allFields) { 

8 // TODO: don't want to project for non-batch bolts...??? 

9 // how to distinguish "batch" streams from non-batch streams? 
10 stream - stream; 

11 . factory = new RootFactory(allFields); 

12 List«String» projected = new ArrayList(allFields.toList()); 
13 projected.remove(0); 

14 project = new ProjectionFactory( factory, new Fields(projected)); 
15 } 

16 

17 public void receive(ProcessorContext context, Tuple tuple) { 


18 TridentTuple t = _project.create(_factory.create(tuple)); 
19 for(TridentProcessor r: receivers) { 
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20 r.execute(context, stream, t); 
21 ) 
22 } 


24 public void addReceiver(TridentProcessor p) { 
25 _receivers.add(p); 
26 } 


28 public Factory getOutputFactory() { 
29 return project; 
30 } 


O factory: RootFactory 对 象 ， 用 于 将 输入 的 Tuple 类 型 的 消息 适 配 为 TridentTuple 类 型 的 消息 。 
Q project: ProjectionFactory 对 象 ， 根 据 输 入 的 需要 对 字段 名 进行 映射 ， 它 的 输入 即 是 
RootFactory 的 输出 。 

口 receivers: 为 TridentProcessor 的 集合 ， 它 将 对 _project 产 生 的 消息 依次 调用 execute 方 法 。 

Q stream: 表示 输入 的 消息 的 StreamId。 

a 第 17~22 行 的 receive 方 法 将 对 输入 的 消息 先 调用 factory 和 _project 的 create 方 法 ， 然 后 
调用 TridentProcessor 的 execute 方 法 。 

口 第 13 行 去 除 输 入 的 消息 的 第 1 列 ， 该 列 为 事务 序号 。 由 于 该 列 所 对 应 的 值 会 反映 在 
ProcessorContext 中 ， 故 这 里 不 再 进行 处 理 。 


23.1.2 成 员 变 量 
类 SubTopologyBolt 的 定义 如 下 : 


public class SubtopologyBolt implements ITridentBatchBolt { 
DirectedGraph graph; 
Set«Node» nodes; 
Map«String, InitialReceiver» roots - new HashMap(); 
Map«Node, Factory» _outputFactories = new HashMap(); 
Map«String, List«TridentProcessor»» _myTopologicallyOrdered = new HashMap(); 
Map«Node, String» _batchGroups; 


} 

首先 来 看 类 中 的 各 个 成 员 变量 。 

Q graph: 整个 Topology 所 对 应 的 有 向 图 。 

QO nodes: 该 Bolt 中 所 包含 的 处 理 节 点 。_nodes 为 _graph 节 点 的 子 集 。 

QO roots: 每 种 类 型 的 输入 流 都 会 对 应 一 个 InitalReceiver 对 象 ， 用 于 表示 如 何 处 理 该 流 的 

消息 。_roots 对 应 于 Subtopology 的 外 部 输入 。 

口 _outputFactories: 每 个 处 理 节 点 都 会 对 应 一 个 输出 的 工厂 。 

Q myTopologicallyOrdered: 它 的 键 为 节点 组 序号 , 值 为 节点 组 所 对 应 的 TridentProcessor。 
这 些 处 理 节 点 的 顺序 为 拓扑 排序 的 结果 ， 这 是 很 关键 的 。 
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Q batchGroups: 该 变量 保存 了 反问 的 索引 ， 用 来 表示 每 个 节点 属于 哪 一 个 节点 组 。 
口 BatchGroup 对 应 于 _graph 中 的 一 个 最 大 连通 子 图 ,例如 ,在 含有 DRPC 的 Topology 中 ,DRPC 


的 节点 与 其 他 节点 是 不 连 


查询 操作 与 存储 操作 可 以 
个 节点 组 的 消息 。 


23.1.3 ”主要 方法 


通 的 ， 它 们 将 属于 不 同 的 节点 组 。 


口 在 一 个 SubTopologyBolt 中 ,含有 多 个 节点 组 是 可 能 的 。 例 如 在 含有 DRPC 的 Topology 中 ， 


被 分 配 到 同一 个 SubTopologyBolt 中 ,于 是 该 Bolt 可 能 收 到 来 自 两 


prepare 方 法 是 SubTopologyBolt 类 中 最 为 核心 的 方法 ， 其 代码 如 下 : 


public void prepare(Map conf 


，TopologyContext context, BatchOutputCollector batchCollector) { 


int thisComponentNumTasks = context.getComponentTasks (context.getThisComponentId()).size(); 


1 

2 

3 for(Node n: nodes) ( 

4 if(n.stateInfo!-null 
5 


) { 


State s = n.stateInfo.spec.stateFactory.makeState(conf, context, 
context.getThisTaskIndex(), thisComponentNumTasks); 


} 


context.setTaskData(n.stateInfo.id, s); 


DirectedSubgraph<Node, Object> subgraph = new DirectedSubgraph(_graph, _nodes, null); 


10  TopologicalOrderIterator it = new Topological0rderIterator<Node, Object>(subgraph) ; 


11 int stateIndex = 0; 
12  while(it.hasNext()) { 


13 Node n = (Node) it.next(); 
14 if(n instanceof ProcessorNode) { 
15 ProcessorNode pn = (ProcessorNode) n; 


16 String batchGroup = _batchGroups.get(n); 

17 if(!_myTopologicallyOrdered.containsKey(batchGroup)) { 

18 _myTopologicallyOrdered.put(batchGroup, new ArrayList()); 

19 } 

20 _myTopologicallyOrdered.get(batchGroup) .add(pn.processor) ; 

21 List<String> parentStreams = new ArrayList(); 

22 List<Factory> parentFactories = new ArrayList(); 

23 for(Node p: TridentUtils.getParents(_graph, n)) { 

24 parentStreams.add(p.streamId); 

25 if( nodes.contains(p)) { 

26 parentFactories.add( outputFactories.get(p)); 

27 ) else ( 

28 if(! roots.containsKey(p.streamId)) { 

29 _roots.put(p.streamId, new InitialReceiver(p.streamId, 
getSourceOutputFields(context, p.streamId))); 

30 } 

31 _roots.get(p.streamId) .addReceiver(pn.processor) ; 

32 parentFactories.add( roots.get(p.streamId).getOutputFactory()); 

33 } 

34 } 

35 List<TupleReceiver> targets = new ArrayList(); 

36 boolean outgoingNode = false; 


37 for(Node cn: TridentUtils.getChildren(_graph, n)) { 
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38 if( nodes.contains(cn)) { 

39 targets.add(((ProcessorNode) cn).processor); 
40 ) else ( 

41 outgoingNode = true; 

42 

43 

44 if(outgoingNode) { 

45 targets.add(new BridgeReceiver(batchCollector)); 
46 

47 

48 TridentContext triContext - new TridentContext( 

49 pn.selfOutFields, 

50 parentFactories, 

51 parentStreams, 

52 targets, 

53 pn.streamlId, 

54 stateIndex, 

55 batchCollector 

56 ); 

57 pn.processor.prepare(conf, context, triContext); 

58 _outputFactories.put(n, pn.processor.getOutputFactory()); 
59 

60 stateIndex++; 

61 


62 // TODO: get prepared one time into executor data... need to avoid the ser/deser 
63  // for each task (probably need storm to support boltfactory) 


a 第 2~8 行 判断 节点 的 stateInfo 是 否 为 空 ， 并 对 存储 的 State 对 象 进行 初始 化 。Sstate 类 是 
Trident 对 存储 的 一 层 抽象 , 也 是 Trident 的 核心 部 分 , 后 面 的 章节 将 对 其 进行 更 为 详细 的 讨 
论 。 初 始 化 过 后 的 State 对 象 被 存储 于 TopologyContext 的 taskData 中 ， 并 以 stateInfo.id 
为 键 。stateInfo.id 是 一 个 以 串 “state” 为 前 缀 的 在 Topology 中 唯一 的 字符 串 。 

O 第 9 行 根据 SubTopologyBolt 中 包含 的 节点 获得 一 个 子 图 。 

a 第 10 行 对 子 图 进行 拓扑 排序 ，Topological0rderIterator 类 型 的 it 变 量 用 来 按照 拓扑 排序 

的 顺序 遍历 子 图 。 

口 第 14 行 ， 可 以 看 到 SubTopologyBolt 只 对 处 理 节 点 进行 操作 。 处 理 节 点 中 包含 了 一 个 

TridentpProcessor。Spout 节 点 和 分 区 节点 则 不 在 SubTopologyBolt 的 处 理 范 围 之 内 。 

口 第 15~19 行 依照 节点 组 序号 的 顺序 ， 将 节点 中 所 含有 的 处 理 器 放 人 和 人 _myTopologically0rdered 变 
量 中 。 例 如 ， 当 subTopologyBolt 要 对 一 个 事务 进行 处 理 时 ， 它 将 按照 myTopologicallyOrdered 
中 的 顺序 依次 调用 TridentProcessor 的 initBatch 和 finishBatch 方 法 。 

O 第 20~34 行 处 理 TridentProcessor 的 输入 。parentStreams 为 TridentProcessor 输 入 流 。 
parentFactories 为 这 些 流 所 对 应 的 工厂 。 第 23 行 获得 该 节点 在 图 中 对 应 的 所 有 父 节 点 。 
第 25~26 行 表示 该 父 节 点 为 SubTopologyBolt 对 应 的 子 图 中 的 某 个 节点 ， 由 于 拓扑 排序 ， 这 个 
节点 已 经 在 之 前 处 理 过 了 , 故 可 以 直接 得 到 该 流 所 对 应 的 输出 工厂 。 第 28~30 行 表示 该 节点 
为 外 部 节点 ， 于 是 根据 其 流 序号 以 及 输出 的 字段 名 构建 一 个 InitialReceiver 对 象 ， 并 将 其 
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放 在 _roots 中 ， 表 示 该 流 来 自 于 外 部 节点 。 第 31 行 将 当前 节点 所 对 应 的 TridentProcessor 
作为 该 流 的 一 个 接收 端 。 

O 第 35~43 行 处 理 该 节点 中 TridentProcessor 的 输出 。 第 35 行 定义 的 targets 变 量 记录 了 “ 哪 
些 节点 的 TridentProcessor 将 处 理 该 节点 的 输出 ”这 一 信息 。 如 果 输 出 的 节点 不 在 
SubTopologyBolt 所 对 应 的 子 图 中 ， 则 将 BridgeReceiver 作 为 其 目标 节点 。 

O 第 48~56 行 构建 了 TridentContext 对 象 ， 可 以 看 出 TridentContext 对 象 是 与 TridentProcessor 
一 一 对 应 的 , 该 对 象 包含 了 TridentProcessor 所 需要 的 上 下 文 环境 (例如, 处 理 需 的 输入 、 
输出 ， 将 要 处 理 的 流 等 等 )。 

口 第 57 行 调用 该 TridentProcessor 的 prepare 方 法 , 它 将 新 产生 的 TridentContext 对 和 象 作为 构 

造 函 数 的 一 个 参数 传人 。 

O 第 58 行 将 该 TridentProcessor 所 对 应 的 输出 添加 到 SubTopologyBolt 的 输出 中 。 于 是 该 输出 

便 可 被 其 他 的 SubTopologyBolt 作 为 输入 了 。 

口 stateIndex 变 量 用 于 唯一 地 标识 SubTopologyBolt 中 的 每 一 个 节点 。 

O 第 62~63 行 提出 了 一 些 建议 ， 和 希望 将 该 方法 中 较为 通用 的 部 分 放置 于 Executor 的 共享 数据 
中 ， 这 样 每 一 个 Task 就 不 需要 再 对 它们 进行 重复 计算 。 

接 下 来 看 execute 方 法 的 实现 : 


@Override 
public void execute(BatchInfo batchInfo, Tuple tuple) { 
String sourceStream = tuple.getSourceStreamId(); 
InitialReceiver ir = roots.get(sourceStream); 
if(ir==null) { 
throw new RuntimeException("Received unexpected tuple " + tuple.toString()); 


ir.receive((ProcessorContext) batchInfo.state, tuple); 


} 

a 首先 , 根据 输入 消息 的 流 号 , TE roots 中 找到 对 应 的 InitialReceiver 对 象 , 并 调用 其 receive 

方法 。 

口 根据 前 面 的 讨论 可 以 知道 ,所 有 等 待 该 流 消息 的 TridentProcessor 的 execute 方 法 均 会 被 调用 。 

O 在 某 个 TridentProcessor 的 execute 方 法 中 ,下 游 TridentProcessor 的 execute 方 法 也 会 被 依 
次 调用 到 ， 于 是 构成 了 一 个 调用 链 ， 直 到 SubTopologyBolt 完 成 对 该 消息 的 处 理 后 结 

finishBatch 和 initBatchstate 方 法 会 被 依照 拓扑 排序 的 节点 顺序 依次 调用 : 


@Override 
public void finishBatch(BatchInfo batchInfo) { 
for(TridentProcessor p: _myTopologicallyOrdered.get(batchInfo.batchGroup)) { 
p.finishBatch((ProcessorContext) batchInfo.state) ; 
} 
} 


@Override 
public Object initBatchState(String batchGroup, Object batchId) { 
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ProcessorContext ret = new ProcessorContext(batchId, new Object[ nodes.size()]); 
for(TridentProcessor p: myTopologicallyOrdered.get(batchGroup)) { 
p.startBatch(ret); 


} 


return ret; 

} 

在 ;initBatchSstate 方 法 中 ， 会 对 ProcessorContext 的 数据 进行 初始 化 ， 然 后 返回 Processor 
Context 对 象 。Trident 中 的 聚集 器 均 要 基于 ProcessorContext 中 state 所 存储 的 数据 来 实现 。 

declareOutputFields 方 法 会 对 SubTopologyBolt 中 每 一 个 节点 的 输出 进行 声明 , 它 将 $batchId 
作为 第 1 列 。 可 以 看 出 SubTopologyBolt 虽 然 作 为 一 个 整体 而 存在 ， 可 其 中 每 一 个 节点 的 输出 均 可 
能 成 为 最 终 的 输出 。 目 前 ， 只 有 BrigeReceiver 的 节点 才 会 真正 发 送 消息 。declare0utput Fields 
方法 的 代码 如 下 : 


@Override 
public void declareOutputFields(OutputFieldsDeclarer declarer) { 
for(Node n: _nodes) { 
declarer.declareStream(n.streamId, TridentUtils.fieldsConcat(new Fields("$batchId"), 
n.allOutputFields)); 


} 

类 BridgeReceiver 的 定义 如 下 : 

public class BridgeReceiver implements TupleReceiver { 
BatchOutputCollector collector; 


public BridgeReceiver(BatchOutputCollector collector) { 
collector - collector; 


} 


@Override 
public void execute(ProcessorContext context, String streamId, TridentTuple tuple) { 
_collector.emit(streamId, new ConsList(context.batchId, tuple)); 


} 
} 


BridgeReceiver 实 现 了 TupleReceiver 接 口 , 其 execute 方 法 负责 将 输入 的 消息 发 送出 去 , 它 将 
ProcessorContext 中 的 batchId 作 为 第 1 列 。 
其 他 方法 都 比较 直观 ， 这 里 不 再 一 一 讨论 。 


23.2 Trident 中 的 Bolt 执行 器 


类 似 于 事务 Topology 中 的 协调 Bolt ，Trident 中 利用 TridentBoltExecutor 来 执行 Trident 中 的 
SubTopologyBolt。 
TridentBoltExecutor 的 实现 与 CoordinatedBolt 的 实现 非常 类 似 ， 不 过 它 设 计 得 更 加 灵活 健 
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Eo 读者 可 以 参考 CooridnatedBolt 的 实现 来 分 析 TridentTopologyBolt, 并 将 二 者 进行 对 比 , 由 此 
可 观察 到 Storm 的 设计 演化 。 


s. 


23.2.1 ITridentBatchBolt##H 


接口 ITridentBatchBolt 的 定义 如 下 : 


public interface ITridentBatchBolt extends IComponent { 
void prepare(Map conf, TopologyContext context, BatchOutputCollector collector); 
void execute(BatchInfo batchInfo, Tuple tuple); 
void finishBatch(BatchInfo batchInfo); 
Object initBatchState(String batchGroup, Object batchId); 
void cleanup(); 


} 

与 IBatchBolt 接 口 相 比 ， 这 个 接口 多 了 initBatchState 方 法 和 cleanup 方 法 。 在 BatchBolt 
Executor 中 ， 为 了 更 好 地 隔离 各 个 事务 ， 每 次 都 需要 反 序 列 化 产生 一 个 新 的 Bolt 对 象 。Trident 寺 
免 了 这 种 情况 的 发 生 ， 在 收 到 节点 组 中 一 个 事务 的 第 一 条 消息 后 ， 将 调用 initBatchstate 方 法 初 
始 化 事务 ， 并 在 结束 时 调用 finishBatch 方 法 ， 从 而 实现 了 事务 隔离 。 


23.2.2 TrackedBatch 


SubTopologyBolt 节 点 中 可 能 会 同时 处 理 来 自 多 个 事务 的 消息 ， 类 TrackedBatch 用 于 跟踪 Bolt 
中 正在 处 理 的 事务 。 该 类 的 数据 成 员 分 析 如 下 : 


public static class TrackedBatch { 
int attemptId; 
BatchInfo info; 
CoordCondition condition; 
int reportedTasks - 0; 
int expectedTupleCount - 0; 
int receivedTuples - 0; 
Map«Integer, Integer» taskEmittedTuples - new HashMap(); 
boolean failed - false; 
boolean receivedCommit; 
Tuple delayedAck - null; 


public TrackedBatch(BatchInfo info, CoordCondition condition, int attemptId) { 
this.info - info; 
this.condition 
this.attemptId 
receivedCommit 


condition; 
attemptId; 
condition.commitStream == null; 


Li Lu Li 


} 


O attemptId 为 事务 尝试 序号 ， 在 Trident 中 为 一 个 递增 的 值 。 
口 info 为 BatchInfo 对 象 。BatchInfo 的 定义 如 下 : 


23.2 
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public class BatchInfo ( 
public IBatchID batchId; 
public Object state; 
public String batchGroup; 
} 


m batchId 目 前 与 事务 尝试 序号 是 等 同 的 。 在 Trident 中 ,处 理 的 数据 都 是 分 批 的 , 可 以 将 其 
理解 成 为 事务 。DRPC Spout 发 送 的 消息 为 查询 消息 ， 这 与 事务 的 概念 就 并 不 一 致 了 。 
但 事实 上， 也 可 以 将 DRPC Spout 发 送 的 消息 及 其 衍生 消息 认为 是 事务 ， 只 不 过 它们 不 
具备 重 传 的 功能 。 因 此 本 书 对 这 两 种 类 型 不 加 区 分 ， 统 称 其 为 事务 。 

state 为 这 个 事务 所 对 应 的 数据 ， 在 initBatchState 时 获得 。 

batchGroup 为 该 事务 所 在 的 节点 组 。 


下 面 回 到 类 TrackedBatch。 


口 condition 为 CoordCondition 对 象 ， 其 定义 如 下 : 


public static class CoordCondition implements Serializable { 
public GlobalStreamId commitStream; 
public int expectedTaskReports; 


Set<Integer> targetTasks; 


口 commitStream 为 一 个 全 局 流 对 象 ， 代 表 这 个 节点 组 中 对 应 的 事务 提交 流 。 

口 expectedTaskReports 表 示 直 接 上 游 节 点 的 个 数 ， 本 节点 将 从 直接 上 游 节 点 接收 数据 。 从 
每 一 个 节点 都 收 到 协调 消息 是 事务 在 该 节点 上 处 理 结束 的 条 件 之 一 。 
O targetTasks 表 示 直 接 下 游 节 点 列表 ， 本 节点 将 向 直接 下 游 节点 发 送 协调 信息 。 


CoordCondition 的 抽象 更 加 直观 : 一 个 事务 在 该 节点 是 否 已 经 完成 ， 取 决 于 三 方面 条 件 ， 首 
先是 所 有 的 上 游 节点 都 已 经 向 该 节点 发 送 了 协调 信息 , 其 次 是 收 到 了 从 事务 提交 流 发 送 过 来 的 事 


务 提交 消息 ， 最 后 是 该 节点 上 收 到 了 确定 的 消 


再 回 到 TrackedBatch。 


判断 事务 是 否 满足 结束 条 件 。 


有 的 消息 均 已 经 发 送出 去 后 ， 


息 数 目 (该 数目 由 协调 消息 给 出 )。 


口 reportedTasks 表 示 已 经 向 该 节点 发 送 过 协调 消息 的 节点 数目 。 
口 expectedTupleCount 表 示 通 过 协调 信息 计算 得 到 的 ， 也 即 为 该 节点 需要 收 到 的 消息 数目 。 


O receivedTuples 表 示 已 经 收 到 的 消息 条 数 。 它 将 与 expectedTupleCount 变 量 进 行 比较 , 来 


Q taskEmittedTuples 表 示 已 经 向 下 游 节点 发 送 的 消息 条 数 。 

口 receivedCommit 表 示 是 否 已 经 从 事务 提交 流 收 到 了 事务 提交 消息 。 

O delayedAck 是 比较 有 趣 的 : 为 了 保证 消息 的 可 靠 传输 , 它 将 保留 至 少 一 个 协调 消息 , 在 所 
再 对 保留 的 消息 进行 Ack。 

口 failed 用 于 表明 当前 事务 是 否 已 经 处 理 失败 。 


通常 情况 下 , 一 个 上 游 节 点 通过 直接 消息 流 来 向 每 一 个 下 游 节 点 发 送 协 调 消 息 , 即便 上 游 节 


点 未 向 其 中 任何 一 个 下 游 节点 发 送 任何 一 条 消息 C 即 协调 消 , 


息 中 的 消息 数目 域 为 0 ), 也 必须 发 送 
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该 协调 消息 。 例 如 ， 系 统 中 存在 节点 类 型 A 和 节点 类 型 B，A 的 并 行 度 为 10，B 的 并 行 度 为 5， 则 B 
的 每 一 个 节点 都 需要 收 到 A 中 每 一 个 节点 的 协调 消息 才 有 可 能 认为 处 理 结束 ， 即 B 的 每 一 个 节点 
都 需要 收 到 10 条 协调 消息 。 

但 是 在 某 些 情况 下 ， 上 游 节 点 若 确定 为 一 个 事务 只 由 其 中 的 某 一 个 节点 产生 时 ， 下 游 节 点 
则 只 需要 收 到 一 条 协调 消息 即 可 。 例 如 ，DRPC Spout A 的 并 行 度 为 10， 类 型 B 的 并 行 度 为 S。 我 
们 知道 ， DRPC Spout 发 送 的 每 条 消息 都 是 独立 请 求 的 ， 于 是 B 中 每 一 个 处 理 节 点 只 要 收 到 从 任意 
一 个 DRPC Spout 发 送 的 协调 消息 即 可 ， 即 B 的 每 一 个 节点 只 需要 收 到 1 条 协调 消息 。 

类 CoordSpec 用 来 描述 当前 节点 与 上 游 节点 的 关系 ， 其 定义 如 下 : 


public static class CoordSpec implements Serializable { 
public GlobalStreamId commitStream = null; 
public Map«String, CoordType» coords = new HashMap«String, CoordType»(); 


public CoordSpec() { 
) 
} 
C] commitSstream 与 CoordCondition 中 的 情况 一 致 ， 表 示 为 全 局 事务 提交 流 。 
口 coords 用 来 描述 每 一 个 上 游 节 点 需要 的 协调 消息 数目 。 
O CoordType 用 来 描述 协调 消息 的 类 型 , 由 直接 上 游 节 点 的 个 数 决 定 。 若 仅 有 一 个 上 游 节点 ， 
则 只 需要 收 到 一 条 协调 消息 即 可 ; 若 含 有 多 个 上 游 节 点 ， 则 需要 收 到 所 有 上 游 节 点 的 协 
调 消息 。 


23.2.3 ”定制 的 输出 收集 器 


TridentBoltExecutor 中 需要 对 发 送 至 每 个 目标 节点 的 消息 数目 进行 统计 。Trident 对 基础 的 输 
出 器 进行 了 包装 ,使 其 可 以 在 发 送 消息 的 同时 ， 更 新 发 送 消息 的 数目 。 该 数目 最 终 将 通过 协调 消 
息 发 送 至 下 游 卓 标 节点 。 类 Coordinated0utputCollector 的 代码 如 下 : 


public class CoordinatedOutputCollector implements IOutputCollector { 
IOutputCollector delegate; 


TrackedBatch _currBatch = null;; 


1 
2 
3 
4 
5 
6 public void setCurrBatch(TrackedBatch batch) { 
7 _currBatch = batch; 

8 

9 

1 


} 
0 public CoordinatedOutputCollector(IOutputCollector delegate) { 
11 _delegate = delegate; 
12 } 
13 
14 public List<Integer> emit(String stream, Collection<Tuple> anchors, List<Object> tuple) { 
15 List<Integer> tasks = _delegate.emit(stream, anchors, tuple); 


16 updateTaskCounts (tasks) ; 
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17 return tasks; 


18 } 
19 


20 public void emitDirect(int task, String stream, Collection<Tuple> anchors, 
List<Object> tuple) { 


21 updateTaskCounts (Arrays.asList(task)); 

22 _delegate.emitDirect(task, stream, anchors, tuple); 
23 } 

24 


25 public void ack(Tuple tuple) { 


26 throw new 
27 } 
28 


IllegalStateException("Method should never be called"); 


29 public void fail(Tuple tuple) { 


30 throw new IllegalStateException("Method should never be called"); 
31 } 

32 

33 public void reportError(Throwable error) { 

34 . delegate.reportError(error); 

35 } 

36 

37 

38 private void updateTaskCounts(List«Integer» tasks) { 

39 if( currBatch!-null) ( 

40 Map«Integer, Integer» taskEmittedTuples = _currBatch.taskEmittedTuples; 
41 for(Integer task: tasks) { 

42 int newCount = Utils.get(taskEmittedTuples, task, O) + 1; 
43 taskEmittedTuples.put(task, newCount); 

44 } 

45 } 

46 } 

47 } 


的 消息 数目 。 


O 类 Coordinated0utputCollector 中 包含 了 一 个 TrackedBatch 类 型 的 _currBatch 对 象 引 用 。 
O 第 38~46 行 的 updateTaskCounts 方 法 根据 输入 的 目标 Task 列 表 ， 更 新 其 发 送 至 该 目标 市 点 


O 第 25~31 行 的 ack 和 fail 实 现 方法 为 空 , 表明 该 输出 收集 器 的 主要 目的 是 发 送 消息 以 及 更 新 


发 送 消 息 的 数目 ， 统 计 输入 消息 的 数目 不 在 其 职责 范围 内 ， 这 与 CoordinatedBolt 的 实现 


是 不 同 的 。 


口 第 6~8 行 ，setCurrBatch 方 法 将 _currBatch 绑 定 到 当前 事务 ， 在 收 到 一 条 消息 时 对 它 进行 


调用 ， 并 在 处 到 


该 消息 之 后 将 其 设 为 空 ， 于 是 CoordinatedOutputCollector 便 可 以 同时 对 


多 个 事务 进行 统计 了 。 
最 后 ， 利 用 BatchoutputCollectorImp1 fil OutputCollector 类 对 Collector 进行 包装 。 
_coorOutputCollector 内 含 更 加 灵活 的 重 载 方法 并 且 具 备 统计 功能 ， 相 关 代 码 如 下 。 


_coordCollector = new CoordinatedOutputCollector(collector); 
 coordOutputCollector = new BatchOutputCollectorImpl(new OutputCollector( coordCollector)); 
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23.24 消息 类 型 


根据 消息 的 来 源 ，Trident 将 消息 划分 为 以 下 3 种 类 型 : 

口 REGULAR 表 示 为 通常 的 数据 消息 ; 

口 COMMIT 表 示 为 事务 提交 消息 ; 

口 COORD 表 示 为 从 上 游 节点 发 送 过 来 的 协调 消息 , 内 容 为 上 游 节点 发 送 给 当前 节点 的 消息 条 数 。 
getTupleType 用 于 计算 输入 消息 的 类 型 ， 相 关 的 分 析 如 下 : 


1 static enum TupleType { 

2 REGULAR, 

3 COMMIT, 

4 COORD 

5} 

6 

7 private TupleType getTupleType(Tuple tuple, TrackedBatch batch) { 
8 CoordCondition cond = batch.condition; 

9 if(cond.commitStream!-null 

10 && tuple.getSourceGlobalStreamid().equals(cond.commitStream)) { 
11 return TupleType.COMMIT; 

12 } else if(cond.expectedTaskReports > 0 

13 && tuple.getSourceStreamId().startsWith(COORD STREAM PREFIX)) { 
14 return TupleType.COORD; 

15 } else { 

16 return TupleType.REGULAR; 

17 } 

18 } 

19 

20 public static String COORD_STREAM_PREFIX = "$coord-"; 

21 


22 public static String COORD_STREAM(String batch) { 

23 return COORD_STREAM_PREFIX + batch; 

24 } 

口 所 有 协调 消息 的 流 都 是 以 “$coord-” 开 头 的 ， 完 整 的 协调 流 名 字 会 在 “$coord-” 后 面 跟 

上 具体 的 节点 组 序号 ， 如 $coord-bg0。 

口 输入 的 消息 来 自 Scommit， 消 息 为 事务 提交 消息 。 

O 若 期 待 上 游 节 点 数目 CexpectedTaskReports ) 大 于 零 ， 且 消息 源 的 流 以 “$coord-” 为 前 
级 ， 则 该 消息 为 协调 消息 。 如 果 收 到 了 以 “$coord-” 为 前 级 的 消息 ， 但 期 待 上 游 节 点 数 
ANA, FMV AM AI FE o 

a 其 他 情况 为 正常 的 数据 消息 。 


23.2.5 ”数据 成 员 分 析 
本 节 对 TridentBoltExecutor 的 数据 成 员 以 及 prepare 方 法 进行 分 析 ， 相 关 代码 如 下 : 


1 Map«GlobalStreamId, String» _batchGroupIds; 
2 Map<String, CoordSpec> _coordSpecs; 
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3 Map«String, CoordCondition»  coordConditions; 
4 ITridentBatchBolt bolt; 

5 long messageTimeoutMs; 

6 long _lastRotate; 

7 OutputCollector collector; 

8 CoordinatedOutputCollector _coordCollector; 

9 BatchOutputCollector _coordOutputCollector; 
10TopologyContext context; 

11 

12 @Override 

13 public void prepare(Map conf, TopologyContext context, OutputCollector collector) { 


14 _messageTimeoutMs = context.maxTopologyMessageTimeout() * 1000L; 
15 _lastRotate = System.currentTimeMillis(); 

16 batches - new RotatingMap(2); 

17 context - context; 

18 collector - collector; 

19 _coordCollector = new CoordinatedOutputCollector(collector); 


20 | coordOutputCollector = new BatchOutputCollectorImpl(new OutputCollector( coordCollector)); 


22 _coordConditions = (Map) context.getExecutorData("  coordConditions"); 

23 if( coordConditions--null) { 

24 _coordConditions = new HashMap(); 

25 for(String batchGroup: _coordSpecs.keySet()) { 

26 CoordSpec spec = _coordSpecs.get(batchGroup) ; 

27 CoordCondition cond = new CoordCondition(); 

28 cond.commitStream = spec.commitStream; 

29 cond.expectedTaskReports = 0; 

30 for(String comp: spec.coords.keySet()) { 

31 CoordType ct = spec.coords.get(comp) ; 

32 if(ct.equals(CoordType.single())) { 

33 cond.expectedTaskReports+=1; 

34 } else { 

35 cond.expectedTaskReports+=context.getComponentTasks(comp).size(); 
36 } 

37 } 

38 cond.targetTasks = new HashSet<Integer>(); 

39 for(String component: Utils.get(context.getThisTargets(), 

40 COORD STREAM(batchGroup), 

41 new HashMap«String, Grouping>()).keySet()) 1 
42 cond.targetTasks .addAll(context.getComponentTasks (component)); 
43 } 

44 _coordConditions.put(batchGroup, cond); 

45 } 

46 context.setExecutorData(" coordConditions", _coordConditions) ; 

47 } 

48 _bolt.prepare(conf, context, _coordOutputCollector) ; 

49 } 


口 _batchGroupsIds 用 来 存储 从 全 局 流 到 节点 组 序号 的 映射 关系 。 

口 _coordSpec 用 来 存储 每 个 节点 组 内 部 节点 协调 消息 的 接收 关系 。 

口 _coordConditions 用 来 存储 每 个 节点 组 内 部 的 协调 条 件 。 参 考 前 面 关于 TrackedBatch 的 实 
现 分 析 ， 可 正确 理解 这 两 个 成 员 变量 中 所 含有 的 信息 。 
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口 _batches 用 来 跟踪 该 节点 正在 处 理 的 事务 。 

口 _bolt 为 TridentBoltExecutor 所 代理 的 Bolt 节 点 ， 目 前 为 SubTopologyBolt 类 型 。 

a 第 5~6 行 用 来 设置 消息 的 超时 ， 与 系统 的 消息 超时 设置 相同 。 

a 第 7~9 行 用 来 设置 系统 的 输出 收集 器 ， 主 要 用 于 向 外 发 送 数据 并 进行 统计 。 

口 成 员 方法 prepare 主 要 用 来 完成 对 成 员 变 量 的 初始 化 。 处 于 同一 个 Executor 的 Task 会 属于 相 
同 的 组 件 ， 这 些 Task 的 协调 消息 设置 是 相同 的 。 于 是 在 第 46 行 ，Trident 将 该 设置 存储 于 
Executor 的 共享 数据 中 。 由 于 Executor 中 的 Task 是 按照 顺序 进行 初始 化 的 ， 故 该 FExecutor 
中 的 其 他 Task 将 直接 获得 这 些 设置 ， 并 不 需要 重新 计算 。 

a 第 29~37 行 根据 CoordType 来 设置 协调 条 件 。Single 类 型 的 CoorType 主 要 用 于 上 游 节点 为 

Spout 类 型 ， 且 该 Spout 的 每 个 事务 只 含有 一 条 消息 的 情况 ， 例 如 DRPC Spout. 

口 第 38~42 行 设置 该 节点 的 目标 接收 节点 。 


23.2.0 主要 成 员 方 法 分 析 


成 员 方法 execute 是 TridentBoltExecutor 的 核心 方法 ， 其 代码 如 下 : 


1 public void execute(Tuple tuple) { 

2 if(tuple.getSourceStreamId().equals(Constants.SYSTEM TICK STREAM ID)) { 
3 long now = System.currentTimeMillis(); 

4 if(now - _lastRotate > _messageTimeoutMs) { 

5 _batches.rotate(); 

6 _lastRotate = now; 

7 } 

8 
9 


return; 
} 
10 String batchGroup = _batchGroupIds.get(tuple.getSourceGlobalStreamid()); 
11 if(batchGroup--null) { 


12 // this is so we can do things like have simple DRPC that doesn't need to use 
batch processing 

13 . coordCollector.setCurrBatch(null); 

14 _bolt.execute(null, tuple); 

15 _collector.ack(tuple) ; 

16 return; 

17 } 


18 IBatchID id = (IBatchID) tuple.getValue(0); 
19 //get transaction id 
20 //if it already exissts and attempt id is greater than the attempt there 


23 TrackedBatch tracked = (TrackedBatch) _batches.get(id.getId()); 


25 // this code here ensures that only one attempt is ever tracked for a batch, so when 
26 // failures happen you don't get an explosion in memory usage in the tasks 

27 if(tracked!-null) ( 

28 if(id.getAttemptId() > tracked.attemptId) { 

29 batches. remove(id.getId()); 

30 tracked - null; 
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31 } else if(id.getAttemptId() < tracked.attemptId) { 

32 // no reason to try to execute a previous attempt than we've already seen 
33 return; 

34 } 

35} 

36 

37  if(tracked--null) { 

38 tracked = new TrackedBatch(new BatchInfo(batchGroup, id, 


_bolt.initBatchState(batchGroup, id)), _coordConditions.get(batchGroup), 
id.getAttemptId()); 


39 _batches.put(id.getId(), tracked); 
40 } 

41 . coordCollector.setCurrBatch(tracked); 
42 


43 TupleType t = getTupleType(tuple, tracked); 
44 . if(t--TupleType.COMMIT) { 


45 tracked.receivedCommit = true; 

46 checkFinish(tracked, tuple, t); 

47 } else if(t--TupleType.COORD) { 

48 int count - tuple.getInteger(1); 

49 tracked. reportedTasks++} 

50 tracked. expectedTupleCount+=count; 

51 checkFinish(tracked, tuple, t); 

52 } else { 

53 tracked. receivedTuples++; 

54 boolean success = true; 

55 try { 

56 _bolt.execute(tracked.info, tuple); 
57 if(tracked.condition.expectedTaskReports==0) { 
58 success = finishBatch(tracked, tuple); 
59 

60 } catch(FailedException e) { 

61 failBatch(tracked, e); 

62 

63 if(success) { 

64 _collector.ack(tuple) ; 

65 } else { 

66 _collector.fail(tuple) ; 

67 } 

68 } 

69 . coordCollector.setCurrBatch(null); 

70 } 


口 Bolt 需 要 跟踪 所 有 正在 被 处 理 的 事务 , 但 由 于 某 些 事务 处 理 失败 , 被 跟踪 的 事务 可 能 不 会 
被 及 时 清理 ， 长 此 下 去 将 导致 内 存 泄露 。 代 码 的 第 2~9 行 对 这 种 情况 进行 了 处 理 ， 这 非常 
类 似 于 Spout 节 点 中 的 消息 超时 技术 ， 即 当 收 到 从 Tick 流 发 来 的 消息 时 ， 系 统 会 对 _batch 
中 较 老 的 数据 进行 超时 处 理 。 

O 第 10~17 行 ， 若 消息 的 来 源流 不 属于 任何 一 个 节点 组 ， 则 不 对 该 消息 进行 跟踪 ， 而 是 直接 

调用 代理 类 的 execute 方 法 ， 并 对 输入 的 消息 进行 Ack。 

O 第 18~40 行 ， 若 为 该 事务 的 第 一 条 消息 或 者 该 消息 所 在 事务 的 尝试 序号 更 大 ， 则 创建 一 个 
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新 
号 
应 
ES 


小 ， 则 表明 无 需 对 该 消息 进行 处 理 。 第 38 行 调用 Bolt 的 initBatchSstate 方 法 对 事务 所 对 


的 事务 跟踪 对 象 tracked。 若 消息 所 在 的 事务 尝试 编号 比 目 前 正在 跟踪 的 事务 的 尝试 纺 


的 数据 进行 初始 化 ， 具 体 地 ， 就 是 调用 每 个 处 理 节 点 的 startBatch 方 法 。 
收 到 控制 消息 时 ,将 检查 事务 在 该 节点 处 是 否 已 经 处 理 结束 。 第 44~46 行 , 若 收 到 的 消息 


类 型 为 事务 提交 消息 , 则 设置 receivedCommit 为 true, 这 是 事务 处 理 结束 的 条 件 之 一 ,第 47~51 


行 ， 
口 第 53~67 行 对 普通 的 数据 消息 进行 处 理 并 完成 Ack。 注 意 ， 若 期 待 消息 来 源 数 目 为 零 ， 则 
直接 调用 finishBatch 方 法 。 

a 由 于 一 个 节点 可 能 同时 处 理 来 自 多 个 事务 的 消息 ， 故 第 41 行 在 处 理 消息 前 设置 上 下 文 对 


象 


若 收 到 的 消息 为 协调 消息 类 型 ， 则 更 新 收 到 的 协调 消息 数目 和 收 到 的 消息 总 数 。 


， 第 69 行 在 处 理 完成 后 设置 上 下 文 为 空 。 这 是 进行 消息 发 送 数 目 统 计 的 关键 。 


在 收 到 控制 消息 后 ， 将 调用 checkFinish 方 法 来 检查 事务 处 理 是 否 已 经 结束 ， 这 个 方法 的 代 


码 如 下 


1 
2 
3 
4 
5 
6 
7 
8 


private void checkFinish(TrackedBatch tracked, Tuple tuple, TupleType type) { 


if(tracked.failed) ( 
failBatch(tracked); 
_collector.fail(tuple) ; 
return; 


} 


CoordCondition cond = tracked.condition; 

boolean delayed = tracked.delayedAck==null 8& 
(cond.commitStream!-null && type==TupleType. COMMIT 
|| cond. commitStream==nul1) ; 

if(delayed) { 
tracked.delayedAck = tuple; 

} 


boolean failed = false; 
if(tracked.receivedCommit && tracked.reportedTasks == cond.expectedTaskReports) { 
if(tracked.receivedTuples == tracked.expectedTupleCount) { 
//Take the tuple as the Anchor 
finishBatch(tracked, tuple); 
} else { 
//TODO: add logging that not all tuples were received 
failBatch(tracked); 
_collector.fail(tuple) ; 
failed = true; 
} 
} 


if(!delayed 8& !failed) { 
_collector.ack(tuple) ; 
} 


O 588-1417, 若 该 节点 为 事务 提交 节点 , 则 将 从 事务 提交 流 收 到 的 消息 作为 最 后 被 Ack 的 控 


制 


消息 。 否 则 ,就 选取 第 一 个 到 达 的 协调 消息 作为 最 后 被 Ack 的 控制 消息 。 只 有 当 属 于 一 
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个 事务 的 消息 全 都 被 处 理 完成 并 发 送 后 ， 才 会 对 这 条 控制 消息 进行 Ack， 这 是 保证 Ack 框 
架 正 常 工作 所 必须 的 步骤 。 

口 第 16~26 行 , 若 已 经 收 到 的 协调 消息 数目 与 期 望 相同 , 期 望 收 到 的 消息 数目 与 实际 收 到 的 消 
息 数目 相同 ( 若 为 事务 提交 节点 , 则 还 需 收 到 事务 提交 消息 ), 那么 此 时 该 节点 对 事务 的 处 
理 可 以 结束 。 接 下 来 ， 调 用 finishBatch 方 法 对 事务 进行 后 处 理 。 协 调 消息 其 实 是 最 后 发 送 
的 ， 阁 已 经 收 到 了 所 有 的 协调 消息 ,但 仍 有 消息 未 收 到 ， 则 直接 对 事务 进行 失败 处 理 。 

下 面 我 们 来 看 finishBatch 的 方法 实现 ， 其 逻辑 是 直观 的 ， 代 码 如 下 : 


1 private boolean finishBatch(TrackedBatch tracked, Tuple finishTuple) { 

2 boolean success = true; 

3 try ( 

4 _bolt.finishBatch(tracked. info) ; 

5 String stream = COORD_STREAM(tracked. info.batchGroup) ; 

6 for(Integer task: tracked.condition.targetTasks) { 

7 _collector.emitDirect(task, stream, finishTuple, new Values(tracked.info.batchId, 
Utils.get(tracked.taskEmittedTuples, task, 0))); 


8 ) 

9 if(tracked.delayedAck!-null) { 

10 _collector.ack(tracked.delayedAck) ; 
11 tracked.delayedAck = null; 

12 

13 } catch(FailedException e) { 

14 failBatch(tracked, e); 

15 success = false; 

16 


17 batches . remove(tracked.info.batchId.getId()); 
18 return success; 

19 } 

a 第 4 行 调用 代理 Bolt 的 finishBatch 方 法 。 

O 第 5~9 行 向 下 游 节点 发 送 协调 消息 。 

口 第 9~12 行 对 最 后 的 控制 消息 进行 Ack。 

O 第 17 行 ， 去 掉 对 该 事务 的 跟踪 。 
failBatch 方 法 较为 直观 ， 代 码 如 下 : 


private void failBatch(TrackedBatch tracked, FailedException e) ( 
if(e!-null && e instanceof ReportedFailedException) { 
. collector.reportError(e); 


tracked.failed - true; 

if(tracked.delayedAck!-null) { 
_collector.fail(tracked.delayedAck) ; 
tracked.delayedAck = null; 

} 


Trident 的 执行 优化 


Trident 中 采用 了 较 多 图 的 算法 ， 


来 对 执行 的 Topology 结 构 进行 优化 ， 与 Bolt 或 Spout 作 为 最 小 


运算 单元 的 传统 Topology 不 同 , Trident 中 定义 了 更 细微 的 执行 单位 。Trident 的 执行 优化 会 尽 可 能 
地 将 运算 放置 在 一 个 SubTopologyBolt 或 Spout 节 点 中 执行 ， 以 提高 运算 效率 ， 降 低 网 络 传输 消耗 。 
本 章 将 首先 讨论 Trident 中 的 节点 类 型 ， 然 后 介绍 执行 优化 算法 。 


24.4 节点 类 型 


所 有 的 Spout 都 会 放 在 一 个 Spout 节 点 中 运行 , 不 会 与 其 他 运算 单元 合并 。Topology 的 一 个 Bolt 
节点 中 ,可 能 还 有 多 个 处 理 节 点 ,每 个 处 理 节 点 对 应 于 用 户 定义 的 操作 。Spout 节 点 与 Bolt 节 点 之 


间 利 用 分 区 节点 进行 连接 ， 它 对 消 


所 示 。 


息 的 分 组 方式 进行 抽象 。Trident 中 节点 类 型 间 的 关系 如 图 24-1 


€ Node 

m equals(Object) boolean 
m hashCode() int 
(m toString() String 


" i t i g 
€ PartitionNode 


© SpoutNode (@writeObject(ObjectOutputStream) void € ProcessorNode 
m readObject (ObjectInputStream) void 


Powered by yFiles 


24.1.1 基本 节点 类 型 


图 24-1 ”Trident 中 的 节点 类 型 


Node 类 为 Topology 所 对 应 的 有 向 图 中 的 节点 ， 理 解 其 成 员 变 量 是 重要 的 ， 该 类 的 代码 如 下 : 


public class Node implements Serializable { 


private static AtomicInteger 


private String nodeld; 


INDEX = new AtomicInteger(0); 


public String name = null; 
public Fields allOutputFields; 
public String streamId; 

public Integer parallelismHint 
public NodeStateInfo stateInfo 
public int creationIndex; 


null; 
null; 


public Node(String streamId, String name, Fields allOutputFields) ( 
this.nodeId = UUID.randomUUID().toString(); 
this.allOutputFields = allOutputFields; 
this.streamId - streamId; 
this.name - name; 
this.creationIndex = INDEX.incrementAndGet(); 


} 


O INDEX: 用 来 给 Topology 中 的 每 一 个 节点 创建 一 个 编号 。 

口 creationIndex: 利用 INDEX 创 建 的 编号 。 这 个 编号 反应 了 该 节点 在 Topology 中 的 层次 关系 。 
在 对 图 进行 拓扑 排序 时 ,编号 大 的 节点 处 于 拓扑 序列 的 后 面 。 例如，DRPC 需 要 创建 一 个 
节点 来 向 DRPC 服 务 需 发 送 结 果 ，Trident 利 用 creationIndex 来 找到 该 节点 的 父 节 点 ， 这 个 
父 节 点 为 DRPC 子 图 中 编号 最 大 的 节点 (未 创建 DRPC 节 点 之 前 )。 

口 nodeId: 一 个 节点 的 全 局 唯一 标识 符 。 

口 name: 节点 名 字 。 该 名 字 会 显示 在 UL 上 面 , 由 于 Trident 创 建 了 较 多 的 隐藏 节点 ， 目 前 对 名 

字 的 支持 并 不 好 ， 通 常 name 域 均 为 空 。 

口 parallelismHint: 表示 该 节点 的 并 行 度 。 同 一 节点 组 中 的 不 同 节点 ， 其 并 行 度 可 能 会 不 

致 ， 通 常会 取 节 点 组 中 最 大 parallelismHint 作 为 整个 节点 组 的 并 行 度 。 

口 stateInfo: 表示 该 节点 是 否 会 进行 存储 。 类 NodeStateInfo 的 定义 如 下 ， 其 中 id 为 全 局 唯 

一 的 State 标 识 符 ，Statespec 则 规定 了 如 何 去 创 建 一 个 存储 对 象 ， 以 及 该 存储 对 象 是 否 要 

求 有 固定 的 分 区 数目 。 


public class NodeStateInfo implements Serializable { 
public String id; 
public StateSpec spec; 
public NodeStateInfo(String id, StateSpec spec) { 
this.id - id; 
this.spec - spec; 


} 


目前 ， 主 要 有 3 种 类 型 的 节点 。 

口 SpoutNode: Spout 节 点 ， 进 一 步 区 分 为 DRPC Spout 类 型 和 基本 Spout 类 型 。 

口 ProcessorNode: 处 理 节点 。 该 类 型 的 节点 会 包含 实际 的 运算 单元 , 是 构成 SubTopologyBolt 
的 主要 部 分 。 

口 PartitionNode: 分 区 节点 。 该 类 型 节点 只 适用 于 描述 节点 的 输出 会 如 何 被 接收 ( 例如 某 
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个 节点 的 流 将 以 何 种 方式 被 其 他 节点 处 理 等 )。 分 区 节点 对 应 于 Storm 中 的 消息 分 组 方式 。 
分 区 节点 是 Topology 执 行 优化 中 最 重要 的 部 分 ， 它 是 节点 组 之 间 的 分 割 节 点 。 


24.1.2 Spout 
Spout 节 点 的 实现 代码 如 下 : 


public class SpoutNode extends Node { 
public static enum SpoutType { 
DRPC， 
BATCH 


) 


public Object spout; 
public String txId; //where state is stored in zookeeper (only for batch spout types) 
public SpoutType type; 


public SpoutNode(String streamId, Fields allOutputFields, String txid, Object spout, SpoutType type) { 
super(streamId, null, allOutputFields); 
this.txId = txid; 
this.spout - spout; 
this.type - type; 


j 

口 _type 成 员 变量 表明 该 Spout 是 否 为 DRPC Spout 节 点 。DRPC Spout 是 较为 特殊 的 ， 它 的 每 

个 事务 都 只 包含 一 条 消息 。 

O txId 成 员 变 量 对 应 于 Spout 节 点 的 名 称 。Trident Spout 中 的 协调 Spout 需 要 在 ZooKeeper 中 存 
储 一 些 元 数据 ，txId 将 作为 在 ZooKeeper 中 元 数据 路 径 的 一 部 分 。 


24.1.3 “处理 节点 
处 理 节点 的 实现 分 析 如 下 : 


public class ProcessorNode extends Node { 


public boolean committer; // for partitionpersist 
public TridentProcessor processor; 
public Fields selfOutFields; 


public ProcessorNode(String streamId, String name, Fields allOutputFields, Fields selfOutFields, 
TridentProcessor processor) { 
super(streamId, name, allOutputFields); 
this.processor - processor; 
this.selfOutFields = selfOutFields; 


} 


Q processor: TiidentProcessor 类 型 的 成 员 变量 ， 它 包含 了 真正 的 计算 单元 。 


O selfOutFields: 该 节点 将 自己 产生 的 新 列 。 

O committer: 一 个 布尔 类 型 的 值 ， 处 理 节 点 在 进行 partitionpPersist 操 作 时 将 其 设 为 真 。 
由 于 partitionPersist 通 常会 向 存储 对 象 中 更 新 数据 ， 那 么 何 时 为 合适 的 更 新 时 机 呢 ? 
_committer 变 量 的 作用 在 于 , 它 可 以 告知 Topology 的 构建 器 , 该 节点 需要 收听 从 协调 Spout 
那里 发 送出 来 的 事务 提交 流 。 在 收 到 某 一 个 事务 的 提交 消息 时 ， 节 点 便 得 知 该 事务 已 经 
被 成 功 处 理 了 ， 也 就 获得 了 一 个 合适 的 更 新 时 机 。 


24.1.4 “分 区 节点 
分 区 节点 的 分 析 如 下 : 


public class PartitionNode extends Node { 
public transient Grouping thriftGrouping; 


//has the streamid/outputFields of the node it's doing the partitioning on 

public PartitionNode(String streamId, String name, Fields allOutputFields, Grouping grouping) { 
super(streamId, name, allOutputFields); 
this.thriftGrouping - grouping; 

} 


private void writeObject(ObjectOutputStream oos) throws IOException { 


oos.defaultWriteObject(); 
byte[] ser - TridentUtils.thriftSerialize(thriftGrouping); 


oos.writeInt(ser.length); 
oos .write(ser); 


} 


private void readObject(ObjectInputStream ois) throws ClassNotFoundException, IOException { 


ois.defaultReadObject(); 

byte[] ser - new byte[ois.readInt()]; 

ois.readFully(ser); 

this.thriftGrouping = TridentUtils.thriftDeserialize(Grouping.class, ser); 


} 
} 


O thriftGrouping 是 分 区 节点 新 增加 的 成 员 变量 。 
O 它 是 通过 Thrift 定 义 文件 产生 的 Grouping 类 型 ， 所 以 会 采用 Thrift 的 序列 化 器 来 实现 序列 化 
和 有 反 序 列 化 方法 ， 并 且 和 覆盖 了 默认 的 序列 化 和 反 序 列 方法 。 
在 Trident 中 ， 可 实现 几 种 定制 的 分 组 方式 来 协助 Topology 的 执行 优化 以 及 使 编程 更 加 方便 ， 
现 统一 介绍 如 下 。 
IdentityGrouping 类 用 来 表示 在 源 端 组 件 的 Task 数 上 日 与 接收 端 组 件 的 Task 数 日 相同 的 情况 
下 ， 源 端的 Task 与 目的 端的 Task 可 以 一 一 对 应 起 来 ， 这 与 直接 分 组 是 非常 类 似 的 。 
在 Topology 的 执行 优化 过 程 中 ， 如 果 两 个 相 邻 的 节点 组 通过 IdentityGrouping 的 方式 进行 了 
连接 ， 则 表示 它们 具有 相同 的 并 行 度 ， 于 是 会 将 这 两 个 节点 组 合并 。 该 类 的 分 析 如 下 : 
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public class IdentityGrouping implements CustomStreamGrouping { 


1 
2 
3 List<Integer> ret = new Arraylist«Integer»(); 

4 Map<Integer, List«Integer»»  precomputed = new HashMap(); 
5 

6 

7 


@Override 
public void prepare(WorkerTopologyContext context, GlobalStreamId stream, 
List<Integer> tasks) { 


8 List<Integer> sourceTasks = new ArrayList<Integer>(context.getComponentTasks (stream 
.get componentId())); 

9 Collections.sort(sourceTasks); 

10 if(sourceTasks.size()!-tasks.size()) ( 

11 throw new RuntimeException("Can only do an identity grouping when 

source and target have same number of tasks"); 

12 ) 

13 tasks = new ArrayList<Integer>(tasks) ; 

14 Collections.sort(tasks); 

15 for(int i-0; i«sourceTasks.size(); i++) { 

16 int s - sourceTasks.get(i); 

17 int t = tasks.get(i); 

18  precomputed.put(s, Arrays.asList(t)); 

19 } 

20 } 

21 


22 @Override 
23 public List<Integer> chooseTasks(int task, List<Object> values) { 


24 List<Integer> ret = _precomputed.get(task) ; 

25 if(ret==null) { 

26 throw new RuntimeException("Tuple emitted by task that's not part 
of this component. Should be impossible"); 

27 } 

28 return ret; 

29 ] 

30 } 


O 定制 的 分 组 方式 需要 实现 CustomStreamGrouping 接 口 。 具体 地 讲 , 就 是 在 prepare 方 法 中 需 
要 传 入 接收 端的 TaskId 列 表 , 在 chooseTasks 方 法 中 需 根据 当前 Task 及 当前 消息 内 容 来 选择 
接收 端的 一 个 或 多 个 节点 。 

口 fet 为 类 成 员 变 量 ， 它 并 没有 被 用 到 ， 可 以 删除 。 

口 _precomputed 用 来 存储 预先 定义 好 的 源 Task 节 点 与 目标 Task 节 点 的 映射 关系 。 由 于 
chooseTasks 要 求 返回 一 个 列表 类 型 , 因此 虽然 _precomputed 中 只 包含 一 个 节点 , 但 它 仍 被 
定义 为 列表 类 型 。 

a 第 7~20 行 实现 prepare 方 法 。 第 8~9 行 获得 所 有 源 端 节点 的 Task 节 点 并 进行 排序 ， 第 10~12 
行 要 求 源 端 以 及 目标 端的 Task 数 目 相 同 ， 否 则 便 不 适用 于 这 种 分 组 方式 了 。 第 15~19 行 构 

建 源 端 与 目标 端 Task 的 一 一 对 应 关系 ， 并 存储 于 _precomputed 类 成 员 变 量 中 。 

O 第 23~29 行 实现 chooseTasks 方 法 。Trident 会 在 源 端 产 生 并 向 外 发 送 一 条 消息 时 会 调用 该 方 
法 ， 其 中 参数 task 表 示 源 端的 TaskId， 参 数 values 表 示 消 息 的 内 容 。IdentityGrouping 并 
不 需要 利用 消息 的 内 容 , 而 只 需要 根据 源 端 的 TaskId 找 到 预先 计算 好 的 目的 端 TaskId 即 可 。 


Hh 
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类 IndexHashGrouping 实 现 的 功能 与 域 分 组 非常 类 似 ， 区 别 在 于 域 分 组 需要 传人 Fields 对 象 
(FRZ ) 来 进行 分 组 ,而 IndexHashGrouping 则 根据 某 一 个 列 的 下 标 来 进行 分 组 。 例 如 在 DRPC 
处 理 中 我 们 知道 ， 第 1 列 为 事务 序号 列 ， 上 且 向 DRPC 发 送 结果 的 节点 需要 按照 事务 序号 进行 连接 。 
于 是 Trident 便 可 以 使 用 IndexHashGrouping 分 组 方式 并 传人 下 标 0， 这 样 只 要 保证 事务 序号 相同 消 
息 就 会 到 达 相 同 的 Bolt 节 点 ， 在 此 基础 上 便 可 以 执行 连接 操作 。IndexHashGrouping 的 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 


«o 


public class IndexHashGrouping implements CustomStreamGrouping { 


public static int objectToIndex(Object val, int numPartitions) { 
if(val==null) return 0; 
else { 
return Math.abs(val.hashCode()) % numPartitions; 


} 


int _index; 
List<Integer> _targets; 


public IndexHashGrouping(int index) { 
_index = index; 


} 


@Override 

public void prepare(WorkerTopologyContext context, GlobalStreamId stream, List<Integer> 
targetTasks) { 
_targets = targetTasks; 

} 


@Override 

public List<Integer> chooseTasks(int fromTask, List<Object> values) { 
int i = objectToIndex(values.get( index), targets.size()); 
return Arrays.aslist( targets.get(i)); 

} 


O 第 2~7 行 ，objectToIndex 函 数 会 根据 列 内 容 及 目标 端的 Task 数 目 ， 以 哈 希 方式 选择 目标 
TaskId。 

a mE 
口 第 18~20 行 的 prepare 方 法 将 获取 目的 端的 Task， 此 处 可 以 只 存储 数目 。 

口 第 23~27 行 的 chooseTasks 方 法 会 从 输入 消息 values 中 获取 第 _index 列 元 素 ， 并 调用 


index 成 员 变 量 用 来 指明 依照 哪 一 列 来 选择 目标 TaskId。 


objectToIndex 来 得 到 目标 TaskId。 
GlobalGrouping 类 将 所 有 由 源 端 Task 产 生 的 消息 都 发 送 到 一 个 特定 的 目的 端 Task， 这 与 全 局 
分 组 所 实现 的 功能 相同 。 该 类 的 代码 如 下 : 


public class GlobalGrouping implements CustomStreamGrouping { 


List«Integer» target; 
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} 


@Override 

public void prepare(WorkerTopologyContext context, GlobalStreamId stream, List<Integer> targets) { 
List<Integer> sorted = new ArrayList<Integer>(targets) ; 
Collections.sort(sorted); 
target = Arrays.asList(sorted.get(0)); 

} 


@Override 

public List<Integer> chooseTasks(int i, List<Object> list) { 
return target; 

} 


GlobalGrouping 会 选取 排序 后 的 TaskId 列 表 中 ， 第 一 个 目的 端 TaskId 作 为 目标 节点 。 


24.2 


执行 优化 算法 


Trident 引 入 节点 组 的 概念 ， 属 于 同一 个 节点 组 的 节点 最 终 将 被 放 和 人 同一 个 Bolt7 点 中 执行 。 
Trident 会 采用 一 些 图 的 算法 来 试图 将 节点 组 合并 ,使 得 尽 可 能 多 的 操作 在 同一 个 Bolt 节 点 中 完成 。 
本 节 将 分 析 如 何 产生 节点 组 以 及 节点 组 的 合并 算法 。 


24.2.1 


T 


节点 组 


节点 组 是 构建 SubTopologyBolt 的 基础 ， 也 是 Topology 中 执行 优化 的 基本 操作 单元 ，Trident 


会 通过 不 断 地 合并 节点 组 来 达到 最 优 处 理 的 目的 。 用 户 可 使 用 类 Group 来 创建 节点 组 ， 其 中 包含 
了 一 组 连通 的 节点 。 该 类 的 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 
9 


public class Group { 


public Set«Node» nodes - new HashSet«Node»(); 
private DirectedGraph«Node, IndexedEdge» graph; 
private String id; 


public Group(DirectedGraph graph, List«Node» nodes) ( 
init(graph); 
this.nodes.addAll(nodes); 
this.graph - graph; 

} 


public Group(DirectedGraph graph, Node n) { 
this(graph, Arrays.asList(n)); 


public Group(Group gi, Group g2) { 
init(g1.graph) ; 
nodes. addAll(g1.nodes) ; 
nodes. addAll(g2.nodes) ; 

} 
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21 

22 private void init(DirectedGraph graph) { 

23 this.graph - graph; 

24 this.id - UUID.randomUUID().toString(); 
25 } 

26 

27 public Set<Node> outgoingNodes() { 

28 Set<Node> ret = new HashSet<Node>(); 

29 for(Node n: nodes) { 

30 ret.addAll(TridentUtils.getChildren(graph, n)); 
31 ) 

32 return ret; 

33 } 

34 

35 public Set<Node> incomingNodes() { 

36 Set<Node> ret = new HashSet<Node>(); 

37 for(Node n: nodes) { 

38 ret.addAll(TridentUtils.getParents(graph, n)); 
39 

40 return ret; 

41 

42 } 


口 nodes 成 员 变 量 表示 该 节点 组 中 含有 的 节点 。 

口 graph 成 员 变量 表示 Topology 节 点 的 有 向 图 。 

口 id 为 GUID 类 型 ， 用 以 唯一 地 标识 一 个 节点 组 。 

口 第 27~33 行 定义 的 outgoingNodes 方 法 , 会 通过 遍历 组 中 节点 的 方式 来 获取 该 节点 组 所 有 节 

点 的 子 节点 ， 这 些 子 节 点 可 能 属于 该 节点 组 ， 也 可 能 属于 其 他 的 节点 组 。 

口 第 35~41 行 定义 的 ijncomingNodes 方 法 用 来 获得 该 节点 组 中 所 有 市 点 的 父 节点 , 这 些 父 节点 

可 能 属于 该 节点 组 ， 也 可 能 属于 其 他 的 节点 组 。 

a 第 16~17 行 的 构造 函数 用 于 合并 两 个 节点 组 gl 和 g2。 第 12~14 行 定义 的 构造 函数 则 用 于 创 
建 只 含 一 个 节点 的 节点 组 。Topology 在 进行 执行 优化 时 , 最 开始 的 状态 即 是 这 种 每 一 个 
理 节点 独立 作为 一 个 节点 组 的 情况 。 

口 第 6~10 行 的 构造 函数 用 来 对 节点 组 进行 初始 化 。 其 中 ， init 函 数 的 作用 仅 为 创建 节点 组 

id， 以 及 对 graph 赋 值 。 


24.2.2 ”节点 组 的 合并 算法 


类 GraphGrouper 提 供 了 对 节点 组 进行 操作 及 合并 的 基本 算法 : 


= 


public class GraphGrouper { 
DirectedGraph«Node, IndexedEdge» graph; 
Set«Group» currGroups; 
Map«Node, Group» groupIndex = new HashMap(); 


} 
O graph 成 员 变 量 的 意义 与 前 面 节点 组 中 的 相同 ， 表 示 Topology 中 节点 的 有 向 图 。 
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O currGroups 表 示 当 前 graph 所 对 应 的 节点 组 。 节 点 组 之 间 是 没有 交集 的 。 


组 的 合并 操作 中 起 到 了 重要 作用 。 
下 面 对 GraphGrouper 中 的 重要 工具 函数 进行 介绍 


public void reindex() ( 
groupIndex.clear(); 
for(Group g: currGroups) ( 
for(Node n: g.nodes) { 
groupIndex.put(n, g); 


} 
} 


nodeGroup 函 数 用 于 查询 某 一 个 节点 所 在 的 节点 组 : 


public Group nodeGroup(Node n) ( 
return groupIndex.get(n); 


) 
T-HriEoutgoingGroupsZifi 
间 存 在 有 向 边 ， 即 两 个 节点 组 是 相连 的 。 其 基本 算法 为 遍历 每 


在 的 节点 组 与 自身 节点 组 不 同 ， 则 获得 子 节点 所 在 的 节点 


public Collection«Group» outgoingGroups(Group g) { 
Set«Group» ret - new HashSet(); 
for(Node n: g.outgoingNodes()) ( 
Group other - nodeGroup(n); 
if(other==null || !other.equals(g)) { 


ret.add(other); 


) 


return ret; 


) 
incomingGroups 方 法 与 outgoingGroups 相 似 ， 用 来 获得 该 
少 存在 一 个 节点 及 一 条 有 向 边 与 该 节点 组 中 的 节点 相连 。 


public Collection«Group» incomingGroups(Group g) { 
Set«Group» ret - new HashSet(); 
for(Node n: g.incomingNodes()) ( 
Group other - nodeGroup(n); 
if(other==null || !other.equals(g)) { 
ret.add(other); 


} 
} 


return ret; 


口 groupIndex 是 一 个 反 向 的 索引 , 用 于 快速 查询 每 个 节点 所 在 的 节点 组 。 该 成 员 变 量 


R 据 输入 节点 组 和 有 向 图 来 计算 : 哪些 节点 组 


reindex 函 数 会 根据 currGroups 来 重新 构建 groupIndex 索 引 。 其 代码 如 下 : 


与 输入 的 节点 组 之 
个 节点 的 子 节点 ,， 若 该 子 节点 所 


点 组 。 该 方法 的 代码 如 下 : 


节点 组 的 父 节 点 组 ， 即 父 节点 组 中 
其 代码 如 下 : 
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注意 变量 other 是 可 能 为 空 的 ， 因 为 在 合并 节点 组 的 算法 中 , 并 不 是 每 次 都 会 重新 更 新 索引 。 
merge 函 数 用 来 合并 两 个 节点 组 。 算 法 为 将 81 和 8g2 从 currGroups 中 去 除 ， 同 时 添加 一 个 新 的 节 
点 组 , 该 节点 组 包含 gL 和 g2 的 所 有 节点 , 最 后 将 groupIndex 更 新 到 新 的 节点 组 。 函数 的 代码 如 下 : 

private void merge(Group g1, Group g2) { 

Group newGroup = new Group(g1, g2); 

currGroups.remove(g1) ; 

currGroups.remove(g2); 

currGroups.add(newGroup); 


for(Node n: newGroup.nodes) { 
groupIndex.put(n, newGroup); 


} 

mergeFully 方 法 是 GraphGrouper 的 核心 算法 ， 它 用 来 计算 何 时 可 以 对 两 个 节点 组 进行 合并 。 
其 基本 思想 为 : 如 果 一 个 节点 组 只 有 一 个 父 节 点 组 ,那么 将 该 节点 组 与 其 父 节 点 组 进行 合并 ; 类 
似 地 ， 如 果 一 个 节点 组 只 有 一 个 子 节 点 组 ,那么 将 子 节 点 组 与 自身 节点 组 进行 合并 ; 反复 进行 这 
两 个 过 程 直 到 没有 满足 以 上 条 件 的 节点 组 为 止 。mergeFully 方 法 的 代码 如 下 : 


1 public void mergeFully() ( 

2 boolean somethingHappened - true; 

3 while(somethingHappened) { 

4 somethingHappened - false; 

5 for(Group g: currGroups) { 

6 Collection«Group» outgoingGroups - outgoingGroups(g); 
7 if(outgoingGroups.size()==1) { 

8 Group out = outgoingGroups.iterator().next(); 

9 if(out!-null) { 

1 


0 merge(g, out); 

11 somethingHappened - true; 

12 break; 

13 } 

14 } 

15 

16 Collection«Group» incomingGroups = incomingGroups(g); 
17 if(incomingGroups.size()==1) { 

18 Group in = incomingGroups.iterator().next(); 
19 if(in!=null) { 

20 merge(g, in); 

21 somethingHappened = true; 

22 break; 

23 } 

24 } 

25 } 

26 } 

27 } 


a F247) Eat somethingHappened HK AN HIT AL RAPP AL, 并 且 已 经 进 
行 了 合并 操作 ， 因 此 需要 进行 下 一 次 迭代 。 
O 第 6~14 行 首先 获得 一 个 节点 组 的 所 有 父 节 点 组 ， 若 父 节 点 组 的 数目 为 1， 则 进行 合并 。 
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口 类 似 地 ， 第 16~25 行 处 理 只 有 一 个 子 节点 组 的 情况 。 


该 类 的 构造 函数 需要 传人 Topology 所 对 应 的 有 向 图 , 以 及 初始 节点 组 initialGroups。 水 数 的 


代码 如 下 : 


public GraphGrouper(DirectedGraph«Node, IndexedEdge» graph, Collection«Group» initialGroups) { 


this.graph - graph; 
this.currGroups - new HashSet(initialGroups); 
reindex(); 


} 


理解 初始 化 节点 组 initialGroups 的 获取 过 程 是 非常 重要 的 。 为 了 达到 这 个 目的 ， 我们 来 分 


析 下 面 这 段 代码 ， 它 摘自 于 文件 TridentTopology.java: 


1 List«SpoutNode» spoutNodes = new ArrayList<SpoutNode>(); 
2 Set«Node» boltNodes = new HashSet«Node»(); 

3 for(Node n: graph.vertexSet()) { 

4 if(n instanceof SpoutNode) { 

5 spoutNodes.add((SpoutNode) n); 

6 ) else if(!(n instanceof PartitionNode)) ( 

7 boltNodes.add(n); 

8 } 

9 } 

10 


11 Set<Group> initialGroups = new HashSet<Group>(); 
12 for(List«Node» colocate: colocate.values()) { 


13 Group g - new Group(graph, colocate); 
14 boltNodes.removeAll(colocate); 

15 initialGroups.add(g); 

16 } 


17 for(Node n: boltNodes) { 
18 initialGroups.add(new Group(graph, n)); 
19 } 


21 GraphGrouper grouper - new GraphGrouper(graph, initialGroups); 
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a 552-9f13811 SAMA PHT, IPR MK a Spout ARB 点。 注意 ， 分 区 


O 第 17~19 行 将 每 一 个 Bolt 节 点 初始 化 为 一 个 节点 组 ， 这 表明 分 区 节点 并 不 属于 任何 的 节点 


组 。 分 区 节点 起 到 了 连接 点 组 的 作用 ， 当 它 出 现时 ， 与 它 连 接 的 节点 所 在 的 节点 组 是 


不 可 能 被 合并 的 。 


O 第 11~16 行 将 colocate 变 量 中 的 节点 组 初始 化 为 同一 个 节点 组 。_colocate 变 量 是 一 个 哈 
希 表 ， 其 键 为 StateIld， 值 为 该 State 上 进行 操作 的 节点 〈 即 对 State 进 行 更 新 和 查询 的 节点 )。 
Trident 会 将 这 两 类 节点 放 在 一 个 节点 组 中 同时 处 理 ， 以 便于 State 的 查询 与 更 新 。 可 以 想 
象 , 如 果 不 把 这 两 类 市 点 放 在 同一 个 节点 组 中 , 查询 操作 将 很 难 完成 。 例 如 , 在 含有 DRPC 
节点 的 Topology 中 ， 进 行 StateQuery 操 作 的 节点 与 PartitionPersist 所 对 应 的 节点 将 会 被 


放 在 同一 个 节点 组 ， 也 即 同 一 个 Bolt 中 执行 。 由 于 这 两 类 节点 可 能 届 
也 为 TridentBoltExecutor 增 加 了 不 少 的 复杂 性 。 


于 不 同 的 节点 组 ， 这 
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a 于 是 可 以 总 结 : 分 区 节点 起 到 分 割 节 点 组 的 作用 ; Trident 会 尽量 地 将 节点 组 合并 , 合并 后 
的 节点 组 将 在 同一 个 Bolt 中 执行 。 


24.2.3 ”处 理 节点 组 中 的 分 区 节点 

为 了 处 理 方便 ，Trident 要 求 节点 组 之 间 一 定 要 用 分 区 节点 来 进行 连接 。 当 然 , 节点 组 与 Spout 
节点 组 之 间 不 需要 满足 此 要 求 。 

下 面 的 代码 段 用 于 进行 异常 情况 处 理 : 


1 for(IndexedEdge«Node» e: new HashSet<IndexedEdge>(graph.edgeSet())) { 

2 if(!(e.source instanceof PartitionNode) 8& !(e.target instanceof PartitionNode)) { 

3 Group g1 = grouper.nodeGroup(e. source) ; 

4 Group g2 = grouper.nodeGroup(e. target) ; 

5 // g1 being null means the source is a spout node 

6 if(gi--null && !(e.source instanceof SpoutNode) ) 

7 throw new RuntimeException("Planner exception: Null source group must indicate a 
spout node at this phase of planning"); 


8 if(gi--null || !g1.equals(g2)) { 

9 graph. removeEdge(e) ; 

10 PartitionNode pNode = makeIdentityPartition(e.source) ; 

11 graph. addVertex(pNode) ; 

12 graph.addEdge(e.source, pNode, new IndexedEdge(e.source, pNode, 0)); 
13 graph.addEdge(pNode, e.target, new IndexedEdge(pNode, e.target, e.index)); 
14 } 

15 } 

16 } 

17 

18 private static PartitionNode makeIdentityPartition(Node basis) { 

19 return new PartitionNode(basis.streamId, basis.name, basis.allOutputFields, 
20 Grouping.custom serialized(Utils.serialize(new IdentityGrouping()))); 

21 } 


a 4518-211TH'makeIdentityParitionPK Zi ge T —4- 3r) PC x. C C eu cB E RR 
IdentityGrouping 的 方式 进行 连接 。 根 据 前 面 的 讨论 ，IdentityGrouping 要 求 源 节 点 与 目 
的 节点 之 间 具 有 相同 的 Task 数 目 。 

a 第 1~16 行 对 有 向 图 中 所 有 的 边 进行 遍历 ， 获 得 每 一 条 边 连 接 的 节点 所 在 的 节点 组 。 第 6~7 
行 表 明 ， 若 源 端 节 点 组 为 空 并 且 其 节点 也 不 是 Spout 节 点 ， 则 处 于 异常 状态 。 知 g1 与 82 所 在 
的 节点 组 不 同 , 则 创建 一 个 新 的 分 区 节点 , 并 将 该 分 区 节点 插入 到 源 节 点 与 目的 节点 之 间 。 

口 通过 这 段 代码 ，Trident 保 证 了 Bolt 节 点 组 之 间 均 通过 分 区 节点 完成 连接 。 


24.2.4 ”节点 组 以 不 同 的 方式 收听 相同 流 


Storm 本 身 并 不 支持 一 个 节点 组 中 的 节点 以 不 同 的 分 组 方式 去 收听 同一 个 流 。 对 于 这 种 情况 ， 
Trident 会 创建 一 个 新 的 等 同 节点 , 以 及 一 个 新 的 分 区 节点 ,使 得 每 个 输入 的 分 区 节点 所 对 应 的 流 
只 存在 一 种 分 组 方式 。 
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externalGroupInputs 方 法 用 于 获得 一 个 节点 组 的 所 有 父 分 区 节点 。 根据 前 面 的 分 析 ， 同 一 个 
节点 组 中 ， 可 以 含有 分 区 节点 ， 但 这 些 分 区 节点 不 会 含有 子 节点 。Bolt 节 点 组 之 间 通 过 分 区 节点 
进行 连接 ， 故 externalGroupInputs 获 得 的 是 一 个 节点 组 的 所 有 外 部 输入 。 注 意 ，incomingNodes 
方法 可 以 返回 一 个 节点 组 内 部 的 节点 。externalGroupInputs 方 法 的 代码 如 下 : 


private static Set«PartitionNode» externalGroupInputs(Group g) { 


Set«PartitionNode» ret - new HashSet(); 


for(Node n: g.incomingNodes()) ( 


} 


if(n instanceof PartitionNode) { 
ret.add((PartitionNode) n); 
} 


return ret; 


extraPartitionInputs 方 法 用 来 计算 得 到 同一 流 的 具有 不 同 分 组 方式 的 分 区 节点 ,其 代码 如 下 : 


1 
2 
3 
4 
5 
6 
7 
8 
9 
1 


JE 
TJ 


private static List«PartitionNode» extraPartitionInputs(Group g) { 


List«PartitionNode» ret = new ArrayList(); 
Set«PartitionNode» inputs - externalGroupInputs(g); 
Map«String, List«PartitionNode»» grouped = new HashMap(); 
for(PartitionNode n: inputs) { 
if(!grouped.containsKey(n.streamId)) { 
grouped.put(n.streamId, new ArrayList()); 


grouped.get(n.streamId).add(n); 


for(List«PartitionNode» group: grouped.values()) { 
PartitionNode anchor - group.get(0); 
for(int i=1; i«group.size(); i++) { 
PartitionNode n = group.get(i); 
if(!n.thriftGrouping.equals(anchor.thriftGrouping)) { 
ret.add(n); 
} 


} 
} 


return ret; 


a 第 2 行 调用 externalGroupInputs 方 法 来 获得 所 有 的 外 部 输入 分 区 节点 。 

O 第 4~10 行 根据 流 的 名 字 对 这 些 分 区 节点 进行 分 组 ， 若 同一 个 流 具 有 多 个 分 区 节点 ， 且 分 
组 方式 不 同 ， 则 将 这 些 节点 返回 。 
O 第 13 行 的 变量 i 是 从 1 开始 的 。 正 如 其 名 称 所 表达 的 意思 ， 函 数 返回 的 为 额外 的 分 区 输入 
点 。 寿 一 个 流 的 所 有 分 区 节点 拥有 相同 的 分 组 方式 ，Trident 则 不 需要 进行 额外 处 理 。 


y> 


c 


下 面 的 代码 完成 了 “节点 组 以 不 同 的 方式 收听 同一 流 ”这 一 特殊 情况 的 处 理 逻 辑 。 另 外 需 注 
意 ， 代 码 中 的 注释 与 实际 的 逻辑 并 不 符合 : 
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// 
// 


// 
// 


// 
// 


// 


if one group subscribes to the same stream with same partitioning multiple times, 

merge those together (otherwise can end up with many output streams created for that 
partitioning 

if need to split into multiple output streams because of same input having different 

partitioning to the group) 


this is because can't currently merge splitting logic into a spout 

not the most kosher algorithm here, since the grouper indexes are being trounced via 
the adding of nodes to random groups, but it 

works out 


List<Node> forNewGroups = new ArrayList<Node>(); 


} 


for(Group g: mergedGroups) { 
for(PartitionNode n: extraPartitionInputs(g)) { 
Node idNode = makeIdentityNode(n.allOutputFields); 
Node newPartitionNode = new PartitionNode(idNode.streamId, n.name, 
idNode.allOutputFields, n.thriftGrouping) ; 
Node parentNode = TridentUtils.getParent(graph, n); 
Set<IndexedEdge> outgoing = graph.outgoingEdgesOf(n); 
graph. removeVertex(n) ; 


graph.addVertex(idNode) ; 
graph.addVertex(newPartitionNode) ; 
addEdge(graph, parentNode, idNode, 0); 
addEdge(graph, idNode, newPartitionNode, 0); 
for(IndexedEdge e: outgoing) { 

addEdge(graph, newPartitionNode, e.target, e.index); 


Group parentGroup = grouper.nodeGroup(parentNode) ; 
if(parentGroup==null) { 
forNewGroups.add(idNode); 
) else ( 
parentGroup.nodes.add(idNode); 
} 


for(Node n: forNewGroups) { 


} 


grouper.addGroup(new Group(graph, n)); 


// add in spouts as groups so we can get parallelisms 
for(Node n: spoutNodes) { 


} 


grouper.addGroup(new Group(graph, n)); 


第 10~32 行 代码 对 每 一 个 节点 组 进行 处 理 ， 第 11 行 对 于 每 一 个 额外 的 分 区 节点 进行 处 理 。 
第 12 行 创建 了 一 个 相同 的 节点 ,该 节点 中 含有 一 个 EachProcessor。EachProcessor 利 用 
TrueFilter 将 输入 的 消息 原封 不 动 地 输出 ,因此 被 称 为 等 同 节点 。 第 13 行 创建 一 个 新 的 分 
区 节点 ,该 节点 的 输入 为 新 创建 的 等 同 节 点 。 

第 16~24 行 对 有 向 图 进行 更 新 。 删 除 掉 老 的 节点 , 插入 新 的 节点 ， 并 更 新 边 的 关系 和 市 点 
组 的 关系 。 
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口 第 34~36 行 将 新 产生 的 节点 设置 为 新 的 节点 组 。 
a 第 39~41 行 将 Spout 节点 作为 节点 组 ， 即 Spout 节点 与 Bolt 的 节点 组 之 间 并 不 进行 合并 。 


24.2.5 ”执行 优化 后 的 节点 组 


完成 了 以 上 的 步骤 , 也 就 基本 上 完成 了 对 有 向 图 中 节点 组 的 优化 。 下 面 的 代码 将 重新 计算 节 
点 所 属 的 节点 组 ， 并 运行 节点 组 的 合并 算法 得 到 mergedGroups。 然 后 ， 利 用 图 论 中 的 最 大 连通 子 
图 算法 获得 connectedComponents 变 量 ， 称 这 样 的 一 个 最 大 连通 子 图 为 一 个 节点 组 。 

Topology 所 对 应 的 有 向 图 中 ， 任 何 一 个 节点 只 能 属于 某 一 个 节点 组 。Bolt 组 件 上 可 以 运行 属 
于 不 同 节点 组 的 节点 。 例如 , 在 含有 DRPC 的 Topology 中 , 某 个 SubTopologyBolt 可 以 运行 DRPC 的 
查询 操作 ， 以 及 数据 的 存储 操作 ， 这 两 个 操作 就 属于 不 同 的 节点 组 。 


grouper.reindex(); 
mergedGroups - grouper.getAllGroups(); 


Map«Node, String» batchGroupMap = new HashMap(); 
List«Set«Node»» connectedComponents - new ConnectivityInspector«Node, IndexedEdge»(graph). 
connectedSets(); 
for(int i=0; i<connectedComponents.size(); i++) { 
String groupId = "bg" + i; 
for(Node n: connectedComponents.get(i)) { 
batchGroupMap.put(n, groupId); 
} 


24.26 ”计算 节点 组 的 并 行 度 


属于 同一 个 节点 组 的 节点 会 在 同一 个 Bolt 中 执行 ， 那么 这 个 Bolt 的 并 行 度 该 如 何 得 到 呢 ? 

Trident 进 一 步 使 用 了 图 的 算法 ， 它 利用 节点 组 作为 图 的 顶点 ， 当 节点 组 之 间 通 过 分 组 方式 为 
IdentityGrouping 的 分 区 节点 进行 连接 时 ， 就 将 这 两 个 节点 组 进行 合并 。 然 后 获得 最 大 连通 子 图 , 并 
在 每 个 连通 子 图 上 计算 并 行 度 , 最 终 便 得 到 了 每 一 个 节点 组 的 并 行 度 。 相 关 的 代码 及 方法 分 析 如 下 : 


1 private static Map«Group, Integer» getGroupParallelisms(DirectedGraph<Node, 
IndexedEdge» graph, GraphGrouper grouper, Collection«Group» groups) { 


2 UndirectedGraph«Group, Object» equivs = new Pseudograph«Group, Object»(0bject.class); 
3 for(Group g: groups) { 

4 equivs.addVertex(g); 

5 

6 for(Group g: groups) { 

7 for(PartitionNode n: externalGroupInputs(g)) ( 

8 if(isIdentityPartition(n)) { 

9 Node parent - TridentUtils.getParent(graph, n); 

10 Group parentGroup = grouper.nodeGroup(parent); 

11 if(parentGroup!-null && !parentGroup.equals(g)) { 


12 equivs.addEdge(parentGroup, g); 
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13 
14 
15 
16 
17 
18 
19 


20 
21 
22 
23 
24 


25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 
44 


口 
口 
口 


口 
口 


口 


} 


Map<Group, Integer> ret = new HashMap(); 
List<Set<Group>> equivGroups = new ConnectivityInspector<Group, Object>(equivs) 
.connectedSets(); 
for(Set<Group> equivGroup: equivGroups) { 
Integer fixedP = getFixedParallelism(equivGroup) ; 
Integer maxP = getMaxParallelism(equivGroup) ; 
if(fixedP!-null 8& maxP!-null && maxP < fixedP) { 
throw new RuntimeException("Parallelism is fixed to 
is less than that: " + maxP); 


} 


" 


+ fixedP + " but max parallelism 


Integer p = 1; 
for(Group g: equivGroup) { 
for(Node n: g.nodes) { 
if(n.parallelismHint!-null) { 
p = Math.max(p, n.parallelismHint) ; 
} 


} 


} 
if(maxP!-null) p = Math.min(maxP, p); 


if(fixedP!-null) p = fixedP; 
for(Group g: equivGroup) { 
ret.put(g, p); 


} 


return ret; 


} 


第 2 行 生 成 一 个 Pseudograph 对 象 ， 它 是 一 种 可 以 在 两 个 节点 之 间 添 加 多 条 边 的 图 。 
第 3~5 行 将 节点 组 作为 equivs 图 的 顶点 。 

第 6~16 行 当 节 点 组 之 间 的 分 组 方式 为 IdentityGrouping 时 ， 则 创建 一 条 边 ， 表示 这 两 个 顶 
点 所 对 应 的 节点 组 将 具有 相同 的 并 行 度 。 

第 18~19 行 获得 equivs 的 最 大 连通 子 图 。 

第 21 行 获得 固定 并 行 度 。StateInfo 对 象 可 以 指定 分 区 数目 ， 表示 它 代表 的 state 对 象 存 在 
多 少 个 分 区 。Trident 认 为 节点 计算 的 并 行 度 最 好 与 State 的 分 区 数目 一 致 。 固 定 并 行 度 通 
过 节点 组 中 含有 State 的 节点 的 分 区 数目 计算 得 到 ， 同 一 个 节点 组 中 不 允许 存在 两 个 节点 
均 含 有 State 对 象 的 情况 , 但 其 分 区 数目 可 以 不 一 致 的 情况 。 当 没有 分 区 的 State 时 ， 固 定 
并 行 度 为 空 。 

第 22 行 计算 最 大 并 行 度 。 最 大 并 行 度 只 对 含有 Spout 的 节点 组 有 效 ， 其 他 类 型 的 节点 组 为 
空 。 它 是 根据 Spout 节 点 中 配置 项 TOPOLOGY_MAX_TASK_PARALLELISM 的 设 定 来 获得 的 。 因 此 ， 
国定 并 行 度 一 定 要 小 于 等 于 最 大 并 行 度 。 
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a 第 28~35 行 计算 初步 的 并 行 度 ， 默 认 的 并 行 度 为 1。 取 节点 中 所 有 节点 的 parallelismHint 
的 最 大 值 作 为 节点 组 的 并 行 度 。 理 解 如 何 产生 节点 组 对 于 设置 并 行 度 是 重要 的 ， 用 户 设 

置 的 parallelismHint 仅 作为 产生 并 行 度 的 参考 而 非 是 最 终 的 并 行 度 。 

a 第 36 行 表示 若 计算 得 到 的 并 行 度 大 于 最 大 并 行 度 ， 则 取 最 大 并 行 度 为 节点 组 的 并 行 度 。 

a 第 38 行 表示 若 固 定 并 行 度 不 为 室 ， 取 固定 并 行 度 为 节点 组 的 并 行 度 。 

口 第 39~41 行 将 节点 组 的 并 行 度 存储 在 结果 中 以 便 返 回 。 


Trident 与 DRPC 


DRPC 是 英文 Distributed Remote Procedure Call 的 缩写 ， 表 示 分 布 式 的 远程 方法 调用 ， 它 是 
Trident 中 重要 的 功能 模块 ,主要 用 于 支持 快速 的 分 布 式 查询 操作 。 你 可 访问 下 面 的 链接 来 获得 有 
关 DRPC 的 更 多 内 容 : https://github.com/nathanmarz/storm/wiki/Distributed-RPC。 

DRPC 的 总 体 结构 如 图 25-1 所 示 ( 该 图 源 自 官方 文档 )。 


Z 
["request-id", "result"] 


o 人 

S + "resu" ~ DRPC 

Qo Topolo 
els : T 


['request-id", "args", "return-info"] 


=) 


图 25-1 DRPC 的 总 体 架 构 


DRPC Server 是 独立 于 Topology 的 DRPC 服 务 妖 , 它 接 收 用 户 的 输入 , 同时 也 作为 DRPC Spout ER 
的 输入 而 存在 。DRPC Spout 从 DRPC 服 务 器 获得 要 执行 的 查询 请 求 ， 并 在 Topology 中 执行 计算 。 
最 终 ，Topology 中 的 某 个 Bolt 会 将 结果 发 送 给 DRPC 服 务 器 ， 再 由 DRPC 服 务 器 返回 给 用 户 。 

DRPC 请 求 通常 以 较 快 的 速度 返回 。 该 请 求 通常 已 经 被 编译 成 为 Topology 中 的 一 部 分 ， 并 与 其 
他 的 节点 一 并 提交 、 运 行 ， 只 不 过 DRPC Spout 只 有 当 存 在 输入 请 求 时 才 会 有 消息 发 送 给 Topology。 

本 章 将 对 DRPC 的 各 个 部 分 进行 介绍 。 
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25.4 DRPC 服务 器 


DRPC 服 务 器 包含 两 部 分 服务 接口 : 一 部 分 用 于 接收 用 户 请 求 并 传递 结果 ， 另 一 部 分 则 用 于 
向 DRPC Spout 提 交 请 求 并 获得 Bolt 节 点 的 计算 结果 。 本 节 对 DRPC 服 务 器 进行 讨论 。 


25.1.4 DRPC 服 务 器 的 成 员 变 量 
首先 来 分 析 DRPC 服 务 器 的 数据 ， 其 代码 如 下 : 


1 (let [conf (read-storm-config) 

2 ctr (atom 0) 

3 id->sem (atom {}) 

4 id->result (atom {}) 

5 id->start (atom {}) 

6 request-queues (atom {}) 

7 cleanup (fn [id] (swap! id->sem dissoc id) 
8 (swap! id->result dissoc id) 


9 (swap! id-»start dissoc id)) 

10 my-ip (.getHostAddress (InetAddress/getLocalHost) ) 

11 clear-thread (async-loop 

12 (fn [] 

13 (doseq [[id start] @id->start] 

14 (when (» (time-delta start) (conf DRPC-REQUEST-TIMEOUT-SECS)) 

15 (when-let [sem (@id->sem id)] 

16 (swap! id-»result assoc id (DRPCExecutionException. 
"Request timed out")) 

17 (.release sem)) 

18 (cleanup id) 

19 

20 TIMEOUT-CHECK- SECS 

21 )) 

22 ]) 


O ct 为 服务 器 端的 计数 器 ， 用 来 为 输入 的 请 求 产 生 一 个 Id。 它 为 atom 类 型 变量 。atom 非 常 
适合 实现 缓存 ， 缓 存 通 常 不 会 跟 其 他 系统 状态 形成 依赖 ， 并 且 对 读 取 的 速度 要 求 更 高 。 
如 果 你 有 一 个 状态 变量 ， 且 不 需要 跟 其 他 状态 变量 协作 ， 这 时 候 就 应 该 使 用 atom。 

口 id->sem 为 atom 类 型 的 哈 希 表 ， 用 来 存储 从 RequestId 到 Semaphore 变 量 的 映射 关系 ， 
Semophore ( 信号 量 ) 可 用 于 不 同 线程 间 的 同步 。DRPC 服 务 器 为 每 一 个 请 求 创建 了 一 个 信 
号 量 ， 因 此 ， 目 前 其 实现 负担 是 较 大 的 。 

口 id->result 为 atom 类 型 的 哈 希 表 ， 用 来 存储 从 RequestId 到 结果 的 映射 关系 。 

口 id->start 为 atom 类 型 的 哈 希 表 ， 用 来 存储 从 RequestId 到 该 请 求 收 到 的 时 间 的 映射 关系 。 

口 cleanup 是 一 个 成 员 函 数 , 用 于 在 请 求 处 理 结束 后 清理 缓存 , 主要 清理 id->sem、 id->result 

和 id->start 绥 存 。 

口 clear-thread 是 服务 器 端的 一 个 独立 线程 ， 它 会 遍历 id->start 哈 硕 表 ， 并 根据 该 请 求 的 
启动 时 间 和 DRPC-REQUEST-TIMEOUT-SECS 定 义 的 时 间 判 断 请 求 是 否 已 经 超时 。 如 果 超 时 , 则 
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将 一 个 异常 放 在 id->result 哈 希 表 中 ,同时 调用 信号 量 的 释放 操作 。 这 样 ， 等 待 结果 的 线 
程 就 会 收 到 这 个 通知 ， 并 发 现 这 一 信息 为 异常 ， 最 终 将 这 一 信息 返回 给 用 户 。 

口 TIMEOUT-CHECK-SECS 变 量 定义 了 clear-thread 执 行 的 时 间 间 隔 。 

口 clear-thread 保 证 了 系统 资源 的 释放 ， 以 及 用 户 在 规定 时 间 内 可 以 得 到 响应 。 

口 fequest-queues 为 atom 类 型 的 哈 希 表 ， 它 的 键 为 函数 名 称 ， 值 为 一 个 队列 ， 表 示 对 应 于 该 
函数 的 所 有 请 求 。 

下 面 的 方法 将 返回 一 个 队列 : 


1 (defn acquire-queue [queues-atom function] 

2 (swap! queues-atom 

3 (fn [amap] 

4 (if-not (amap function) 

5 (assoc amap function (ConcurrentLinkedQueue. ) ) 
6 amap) 

7 

8 


)) 


(@queues-atom function) ) 


口 swap! 将 对 输入 的 atom 类 型 的 哈 希 表 进 行 操作 ， 其 结果 为 fn 执行 的 结 
口 第 4 行 ， A 含有 键 funciton， IRIE A CaneuirentLinked Quee Si 数 名 称 相 关联 。 


AA 


a 第 8 行 返回 ConcurrentLinkedoueue， 表 示 输 入 为 函数 的 请 求 队列 。 


25.1.2 DRPC 用 户 接口 及 其 实现 


这 部 分 接口 主要 提供 给 用 户 使 用 ， 用 于 向 DRPC 服 务 器 提交 查询 并 等 待 返回 。 该 接口 的 代码 
如 下 : 


1 (reify DistributedRPC$Iface 

2 (^string execute [this ^String function ^String args] 
3 (log-debug "Received DRPC request for " function " " 

currentTimeMillis)) 

4 (let [id (str (swap! ctr (fn [v] (mod (inc v) 1000000000)))) 
5 ^Semaphore sem (Semaphore. O) 

6 req (DRPCRequest. args id) 
7 
8 


args " at " (System/ 


^ConcurrentLinkedQueue queue (acquire-queue request-queues function) 


] 


9 (swap! id-»start assoc id (current-time-secs)) 

10 (swap! id-»sem assoc id sem) 

11 (.add queue req) 

12 (log-debug "Waiting for DRPC result for " function " " args " at " (System/ 
currentTimeMillis)) 

13 (.acquire sem) 

14 (log-debug "Acquired DRPC result for " function " " args " at " (System/ 
currentTimeMillis)) 

15 (let [result (@id->result id)] 

16 (cleanup id) 

17 (log-debug "Returning DRPC result for " function " " args " at " (System/ 


currentTimeMillis)) 
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18 (if (instance? DRPCExecutionException result) 
19 (throw result) 

20 result 

21 )))) 


口 DRPC 面 向 用 户 的 部 分 只 有 execute 方 法 ， 它 的 参数 为 函数 名 字 ， 以 及 该 函数 所 对 应 的 参 
数 。 在 Topology 中 ， 每 个 函数 名 都 会 对 应 于 一 个 DRPC Spout。 

a 第 4 行 ， 产生 该 请 求 的 序号 RequestId。 它 通过 对 ctr 对 象 进行 自 增 并 模 除 1000000000 得 到 。 
a 第 5 行 产 生 一 个 信号 量 。 

口 第 6 行 构建 DRPCRequest 对 象 。 

OQ 第 7 行 获 得 与 请 求 函数 相对 应 的 请 求 队列 。 

口 第 9~11 行 更 新 id->start 和 id->sem 绥 存 ， 同 时 将 请 求 req 放 入 队列 。 

a 第 13 行 开始 等 待 信号 量 sem 的 释放 。 只 有 当 结 果 返 回 或 者 超时 时 ， 第 13 行 才 会 返回 内 容 。 
a 第 15$~21 行 对 返回 的 结果 进行 处 理 ， 若 为 DRPCExecutionException 则 抛 出 异常 ， 其 他 情况 
则 将 结果 返回 。 


25.1.3 DRPC Topology 端 接口 及 其 实现 


这 部 分 接口 对 应 于 Storm 的 Topology。Topology 的 DRPC Spout 节 点 从 DRPC 服 务 器 获取 请 求 并 
进行 处 理 。 相 关 的 代码 如 下 : 


1 DistributedRPCInvocations$Iface 


2 (^void result [this ^String id ^String result] 

3 (let [^Semaphore sem (@id->sem id)] 

4 (1og-debug "Received result " result " for " id " at " (System/currentTimeMillis)) 
5 (when sem 

6 (swap! id-»result assoc id result) 

7 (.release sem) 

8 ))) 

9 (^void failRequest [this ^String id] 

10 (let [^Semaphore sem (@id->sem id)] 

11 (when sem 

12 (swap! id->result assoc id (DRPCExecutionException. "Request failed")) 
13 (.release sem) 

14 

15 (^DRPCRequest fetchRequest [this ^String func] 

16 (let [^ConcurrentLinkedQueue queue (acquire-queue request-queues func) 

17 ret (.poll queue)] 

18 (if ret 

19 (do (log-debug "Fetched request for " func " at " (System/currentTimeMillis)) 
20 ret) 

21 (DRPCRequest. "" "")) 

22 )) 


口 第 15~22 行 实现 fetchRequst 方 法 , 该 方法 将 被 DRPC Spout 调 用 。 其 输入 参数 为 func, 代表 
函数 名 字 。 
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a 第 16 行 获得 与 该 函数 相对 应 的 请 求 队列 ， 第 17 行 返回 一 个 请 求 rzet ( 注意 poll 操 作 是 阻塞 
的 )。 如 果 ret 不 为 空 ， 那么 返回 ret， 否 则 构建 一 个 空 的 DRPCRequest。 该 请 求 并 不 会 被 真 
正 执 行 。 

口 第 2~8 行 实现 result 方 法 ， 该 方法 被 Topology 中 某 个 Bolt 调 用 ， 用 于 返回 某 一 请 求 的 结 

第 6~7 行 将 结果 存储 到 id->result 中 ， 同 时 释放 信号 量 通 知 结果 将 要 到 来 。 若 不 存在 对 应 
的 sem 信 号 量 ， 则 表示 该 请 求 已 经 由 于 超时 或 者 其 他 原因 而 结束 了 。 

O 第 9~14 行 实现 fail 方 法 。 若 查询 失败 ， 则 将 DRPCExecutionException 放 和 结果 中 ， 并 释放 
信号 量 。 同 样 地 ， 该 方法 也 会 被 Topology 中 的 某 个 Bolt 调 用 。 


25.1.4 ”启动 DRPC 服 务 器 
DRPC 服 务 器 是 基于 Thrift 的 TServer 来 实现 的 ， 所 以 代码 较为 简单 : 


(defn launch-server! 


1 
2 
3 (let [conf (read-storm-config) 

4 worker-threads (int (conf DRPC-WORKER-THREADS)) 

5 queue-size (int (conf DRPC-QUEUE-SIZE)) 

6 service-handler (service-handler) 

7 ;; requests and returns need to be on separate thread pools, since calls to 
8 ;; "execute" don't unblock until other thrift methods are called. So if 

9 33 64 threads are calling execute, the server won't accept the result 

1 


0 ;; invocations that will unblock those threads 
11 handler-server (THsHaServer. (-» (TNonblockingServerSocket. (int (conf 
DRPC-PORT))) 

12 (THsHaServer$Args.) 

13 (.workerThreads 64) 

14 (.executorService (ThreadPoolExecutor. 
worker-threads worker-threads 

15 60 TimeUnit/SECONDS (Array 

BlockingQueue. 
queue-size) ) ) 

16 (.protocolFactory (TBinaryProtocol$Factory.)) 

17 (.processor (DistributedRPC$Processor. 
service-handler)) 

18 ) 

19 invoke-server (THsHaServer. (-» (TNonblockingServerSocket. (int (conf 

DRPC-INVOCATIONS-PORT) ) ) 

20 (THsHaServer$Args. ) 

21 (.workerThreads 64) 

22 (.protocolFactory (TBinaryProtocol$Factory.)) 

23 (.processor (DistributedRPCInvocations 
$Processor. service-handler)) 

24 ))] 

25 

26 (.addShutdownHook (Runtime/getRuntime) (Thread. (fn [] (.stop handler- 

server) (.stop invoke-server)))) 
27 (log-message "Starting Distributed RPC servers...") 
28 (future (.serve invoke-server)) 


29 (.serve handler-server)))) 
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a 第 4 行 的 worker-threads 为 线程 池 中 线程 的 数目 ， 


由 于 目前 的 execute 方 法 采 月 


sk, 即 只 有 当 获 得 查询 结果 时 才 返 回 , 这 就 导致 日 


同时 执行 。 


明了 阻塞 方 


和 最 多 只 能 有 worker-threads 个 请 求 被 


a 第 11 行 实例 化 handler-server， 用 于 接收 用 户 的 请 求 , 它 是 基于 THsHaServer 的 。 第 17 行 传 
人 DistributedRPC$Processor 的 实现 来 处 理 请 求 。DRPC-PORT 定 义 hanlder-server 来 收听 的 


端口 号 。 


口 第 19 行 实例 化 invoke-server ， 它 也 是 基于 THsHaServer 的 ， 传 人 DistributedRPCInvoca 
tions$IFace 的 实现 来 处 理 请 求 。DRPC-INVOCATIONS-PORT 定 义 了 invoke-server 收 听 的 端口 号 。 
a 第 28~29 行 启动 nvoke-server 和 handler-server。 这 里 使 用 future 来 启动 一 个 线程 ， 并 执 


行 一 系列 的 表达 式 , 执行 完成 时 线程 会 被 回收 。 这 行 代码 返回 了 一 个 future 类 型 的 对 象 以 
方便 之 后 的 引用 。 之 所 以 使 用 future 方 法 ， 是 为 了 以 非 阻 塞 的 方式 调用 invoke-servez 的 
server 方 法 ， 人 然后 以 阻塞 的 方式 调用 handler-server 的 server 方 法 。 


关于 Thrift 服务 器 的 更 多 信息 ， 请 参考 Thrift 的 相关 文档 。 


25.2 DRPC 的 客户 端 


Storm 中 提供 了 两 个 DRPC 的 客户 端 类 ， 主 要 是 对 Thrift 产 生 的 客户 端 进行 包装 以 方便 之 后 的 


使 用 。 


口 DRPCClient: 用 于 访问 handler-server。 
下 面 简要 分 析 DRPCClient 的 主要 代码 ， 具 体 如 下 : 


口 DRPCInvocationsClient: 用 于 访问 ijnvoke-server。 


1 public class DRPCClient implements DistributedRPC.Iface { 
2 private TTransport conn; 

3 private DistributedRPC.Client client; 

4 private String host; 

5 private int port; 

6 private Integer timeout; 

7 

8 public DRPCClient(String host, int port, Integer timeout) { 
9 try ( 

10 this.host - host; 

11 this.port - port; 

12 this.timeout = timeout; 

13 connect(); 

14 } catch(TException e) { 

15 throw new RuntimeException(e); 

16 } 

17 } 

18 

19 private void connect() throws TException { 

20 TSocket socket = new TSocket(host, port); 


21 if(timeout!-null) { 
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22 socket.setTimeout(timeout); 

23 } 

24 conn = new TFramedTransport (socket) ; 

25 client = new DistributedRPC.Client(new TBinaryProtocol(conn)); 
26 conn.open(); 

27 } 

28 

29 public String execute(String func, String args) throws TException, DRPCExecutionException { 
30 try { 

31 if(client==null) connect(); 

32 return client.execute(func, args); 

33 } catch(TException e) { 

34 client = null; 

35 throw e; 

36 } catch(DRPCExecutionException e) { 

37 client = null; 

38 throw e; 

39 } 

40 

41 } 


O 第 3 行 定义 DistributedRPC.Client 的 对 象 client。 该 类 是 由 Thrift 定 义 文件 产生 的 。 

口 第 19~27 行 定义 connect 方 法 。 首 先 定义 Tsocket 对 象 并 构建 DistributedRPC.CLient 对 象 ， 

然后 调用 TSocket 的 open 方 法 来 建立 连接 。 

口 第 29~39 行 调用 client 的 execute 方 法 ， 参 数 为 函数 名 称 func， 以 及 函数 的 参数 arfgs。 当 有 
异常 发 生 时 ， 将 对 client 对 象 进 行 重 置 ， 客 户 端 代码 可 以 捕获 异常 并 完成 这 种 重 试 。 

可 以 看 出 ， 该 类 是 对 Thrift 产生 的 客户 端 代码 的 包装 。 


25.3 DRPC m Spout 节点 


DRPC Spout 节 点 从 DRPC 服 务 器 获得 请 求 , 并 将 请 求 以 消息 的 形式 发 送 到 Topology。 在 Trident 
中 , DRPC 的 处 理 逻 辑 被 编译 成 为 Topology 的 一 部 分 。DRPC 的 请 求 最 终 被 转换 成 为 对 一 个 存储 对 
象 的 查询 。 

DRPC Spout 需 要 对 发 送出 去 的 消息 进行 跟踪 。 类 DRPCMessageId 为 其 定义 MessageId 的 结构 , 
其 中 成 员 变 量 id 为 请 求 序 号 ，index 为 DRPCClient 的 序列 号 。 根 据 index 可 以 得 到 这 个 请 求 是 从 哪 
个 DRPC 服 务 器 获得 的 ， 并 最 终 将 结果 发 送 至 该 服务 器 。 集 群 中 可 以 存在 多 个 DRPC 服 务 器 ， 用 
户 的 请 求 会 被 发 送 到 其 中 的 一 个 服务 器 上 ，DRPC 从 该 服务 器 获得 请 求 并 进行 处 理 。DRPC 服 务 
器 之 间 不 存在 重复 或 备份 关系 。 因 此 ，DRPC 的 消息 中 需要 含有 消息 id 和 DRPC 服 务 器 序号 。 类 
DRPCMessageId 的 定义 如 下 : 


private static class DRPCMessageId { 
String id; 
int index; 


public DRPCMessageId(String id, int index) ( 
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this.id = id; 
this.index - index; 


} 
接 下 来 分 析 DRPC Spout 的 实现 ， 相 关 代 码 如 下 : 


public class DRPCSpout extends BaseRichSpout { 
public static Logger LOG = LoggerFactory.getLogger(DRPCSpout.class) ; 


SpoutOutputCollector collector; 

List«DRPCInvocationsClient» clients = new ArrayList<DRPCInvocationsClient>(); 
String function; 

String local drpc id - null; 


public DRPCSpout(String function) { 
function - function; 
} 


public DRPCSpout (String function, ILocalDRPC drpc) { 
_function = function; 
_local_drpc_id = drpc.getServiceId(); 

口 _collector 为 基本 的 Spout0utputCollector 类 型 ， 用 于 发 送 消 息 。 

口 _clients 为 DRPC 服 务 器 的 客户 端 ， 为 DRPCInvocationsClient 类 型 。 由 于 DRPC 服 务 器 和 
DRPC Spout 都 有 可 能 存在 多 个 实例 ， 所 以 同一 个 Spout 可 能 需要 与 多 个 DRPC 的 服务 器 进 
行 连接 。 

口 _function 为 该 DRPC Spout 要 处 理 的 函数 。 一 种 类 型 的 DRPC Spout 只 能 处 理 一 种 类 型 的 

口 _local drpc_id 用 来 标识 是 否 为 模拟 模式 ， 为 空 则 表示 为 非 模拟 模式 。 模 拟 模式 与 Topology 

的 模拟 运行 相关 。 

口 构造 函数 的 参数 主要 为 函数 的 名 称 。 

DRPC Spout 的 open 函 数 实现 了 一 个 简单 的 负载 均衡 算法 ， 其 代码 如 下 : 


1 public void open(Map conf, TopologyContext context, SpoutOutputCollector collector) { 
2 collector - collector; 

3 if( local drpc id--null) { 

4 int numTasks = context.getComponentTasks (context.getThisComponentId()).size(); 
5 int index - context.getThisTaskIndex(); 

6 

7 int port - Utils.getInt(conf.get(Config.DRPC INVOCATIONS PORT)); 

8 List<String> servers = (List<String>) conf.get(Config.DRPC SERVERS); 

9 if(servers == null || servers.isEmpty()) { 

10 throw new RuntimeException("No DRPC servers configured for topology"); 

11 

12 if(numTasks < servers.size()) { 

13 for(String s: servers) { 


14 _clients.add(new DRPCInvocationsClient(s, port)); 
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15 } 

16 } else { 

17 int i = index % servers.size(); 

18 _clients.add(new DRPCInvocationsClient(servers.get(i), port)); 
19 } 

20 } 

21 } 


O 第 3 行 表示 open 函 数 主要 处 理 非 模拟 模式 , 它 从 DRPC_SERVERS 配 置 项 获取 DRPC 服 务 器 的 地 址 。 
O 第 12~15 行 ,如果 Spout 的 并 行 度 比 DRPC 服 务 器 的 数目 少 ， 则 每 一 个 DRPC Spout 都 会 含有 
一 个 到 DRPC 服 务 器 的 连接 。 
a 第 17~19 行 ， 如 果 Spout 的 并 行 度 大 于 DRPC 的 服务 器 数目 ， 则 只 连接 特定 的 DRPC 服 务 器 。 
目前 的 这 个 算法 还 是 比较 简单 的 。 
DRPC Spout 的 输出 含有 两 列 : args 表 示 函 数 的 参数 ，return-info 的 模式 为 <requestId，host， 
port>， 用 来 标识 该 请 求 是 从 哪个 DRPC 服 务 器 获得 的 : 


@Override 

public void declareOutputFields(OutputFieldsDeclarer declarer) { 
declarer.declare(new Fields("args", "return-info")); 

} 


下 面 来 看 DRPC Spout 中 nextTuple 函 数 的 实现 ; 
1 public void nextTuple() ( 


2 boolean gotRequest - false; 

3 if( local drpc id--null) { 

4 for(int i-0; i« clients.size(); i++) { 

5 DRPCInvocationsClient client = clients.get(i); 

6 try { 

7 DRPCRequest req = client.fetchRequest(_function) ; 

8 if(req.get_request_id().length() > 0) { 

9 Map returnInfo = new HashMap(); 

10 returnInfo.put("id", req.get request id()); 

11 returnInfo.put("host", client.getHost()); 

12 returnInfo.put("port", client.getPort()); 

13 gotRequest - true; 

14 _collector.emit(new Values(req.get func args(), JSONValue.toJSONString 
(returnInfo)), new DRPCMessageId(req.get request id(), i)); 

15 break; 

16 } 

17 } catch (TException e) { 

18 LOG.error("Failed to fetch DRPC result from DRPC server", e); 

19 } 

20 } 

21 } 

22 if(!gotRequest) { 

23 Utils.sleep(1); 

24 } 
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a 第 4~19 行 依次 遍历 DRPC 服 务 器 的 客户 端 并 调用 fetchRequst 方 法 。 如 果 返 回 了 非 空 的 请 
求 ， 则 构建 一 条 消息 并 发 送出 去 ， 消 息 的 内 容 为 请 求 函 数 的 参数 和 序列 化 后 的 请 求 源 的 
言 息 。 它 使 用 通过 请 求 序号 和 服务 器 索引 构建 的 DRPCMessageId 对 和 象 来 跟踪 消息 。 

口 请 求 序 号 会 起 到 事务 序号 的 作用 。 在 Trident 中 ， 该 序号 被 放 在 了 默认 的 第 1 列 ， 因 此 这 里 
没有 办 法 再 去 放置 消息 源 的 信息 。 目 前 ，Trident 采 用 连接 (join ) 的 方式 来 解决 这 个 问题 : 
即 产生 最 终结 果 的 Bolt 节 点 将 同时 接收 DRPC Spout 发 来 的 消息 和 从 其 他 Bolt 节 点 发 送 来 
的 结果 消息 ， 然 后 按照 请 求 序号 进行 连接 ， 以 获得 请 求 的 来 源 信息 ， 并 最 终 将 结果 发 送 
到 DRPC 服 务 器 。 

O 由 于 请 求 序 号 起 到 了 事务 序号 的 作用 ,产生 结果 的 Bolt 只 有 在 收 到 DRPC Spout 发 送 的 消息 
以 及 从 其 他 Bolt 发 送 过 来 的 结果 之 后 ，finishBatch 方 法 才 会 被 调用 。 

接 下 来 ， 看 一 下 fail 方 法 的 实现 代码 : 

public void fail(Object msgId) { 


DRPCMessageId did = (DRPCMessageId) msglId; 
DistributedRPCInvocations.Iface client; 


if( local drpc id -- null) ( 
client - clients.get(did.index); 
) else { 
client = (DistributedRPCInvocations.Iface) ServiceRegistry.getService(_local_drpc_id); 


try { 
client. failRequest(did.id); 
} catch (TException e) { 
LOG.error("Failed to fail request", e); 


} 
} 
当 消 息 处 理 失 败 后 ，DRPC Spout 的 fail 方 法 将 被 调用 ， 它 根据 msgId 找 到 请 求 的 来 源 ， 然 后 
通过 client 的 failRequest 方 法 通知 DRPC 服 务 器 。 
目前 ，ack 方 法 不 需要 完成 任何 任务 。 当 ack 方 法 被 回调 时 ，DRPC 服务 器 已 经 收 到 了 从 Bolt 
发 送 的 结果 。 将 来 可 以 在 此 处 增加 一 些 清理 操作 等 。 


public void ack(Object msgId) { 
} 


DRPC Spout 是 Trident 中 几 个 基本 Spout 类 型 之 一 。 


25.4 DRPC Spout 的 执行 器 


类 RichSpoutBatchTriggerer 在 一 定 程度 上 完成 了 类 似 于 TridentBoltExecutor 的 功能 。 CRZ 
协调 消息 ,并 利用 这 些 消 息 来 判断 属于 同一 个 事务 的 消息 是 否 处 理 结束 ,目前 主要 用 于 封装 DRPC 
Spout。 该 类 的 代码 如 下 : 
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public class RichSpoutBatchTriggerer implements IRichSpout { 


String stream; 
IRichSpout delegate; 
List<Integer> _outputTasks; 
Random _rand; 
String _coordStream; 
Map<Long, Long> _msgIdToBatchId = new HashMap(); 
Map«Long, FinishCondition» _finishConditions = new HashMap(); 
public RichSpoutBatchTriggerer(IRichSpout delegate, String streamName, String batchGroup) { 
_delegate = delegate; 
_stream = streamName; 
_coordStream = TridentBoltExecutor.COORD STREAM(batchGroup); 


} 


O _stream 为 通常 的 消息 流 。 

口 _coordStream 用 于 发 送 协调 消息 ， 该 流 的 前 级 为 “$coord-”， 这 与 TridentBoltExecutor 是 

相同 的 。 

口 _delegate 是 被 封装 的 Spout。 

O outputTasks 为 接收 该 Spout 消 息 的 Bolt 节 点 。 

口 _rand 为 一 个 随机 数 产 生 右 ， 产 生 的 随机 数 用 于 进行 消息 跟踪 。 

口 _msgIdToBatchId 为 从 消息 跟踪 序号 到 事务 序号 的 映射 关系 。 在 DRPC Spout 中 ， 消 息 跟踪 
序号 为 请 求 序 号 。 同一 条 消息 可 能 被 多 个 Task 接 收 , 而 每 个 接收 端 都 会 对 应 于 一 个 新 的 事 
务 序号 。 

口 _finishContions 主 要 用 来 表示 一 条 消息 是 否 已 经 处 理 完成 ， 它 的 键 为 Messageld 。 
FinishCondition 包 含 _delete 发 送 消息 携带 的 Messageld 和 BatchId 的 集合 。 

类 stream0verrideCollector 对 基本 的 Spout0utputCollect 进 行 了 封装 ， 其 代码 如 下 : 


class StreamOverrideCollector implements ISpoutOutputCollector { 


SpoutOutputCollector collector; 


1 
2 
3 
4 
5 public StreamOverrideCollector(SpoutOutputCollector collector) { 
6 collector - collector; 

7 

8 


} 
9 @Override 
10 public List<Integer> emit(String ignore, List«Object» values, Object msgId) { 
11 long batchIdVal = _rand.nextLong(); 
12 Object batchId = new RichSpoutBatchId(batchIdVal); 
13 FinishCondition finish = new FinishCondition(); 
14 finish.msgId = msgId; 
15 List<Integer> tasks = collector.emit( stream, new ConsList(batchId, values)); 
16 Set<Integer> outTasksSet = new HashSet<Integer>(tasks) ; 
17 for(Integer t: _outputTasks) { 
18 int count = 0; 
19 if(outTasksSet.contains(t)) { 


20 count = 1; 
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21 } 

22 long r = _rand.nextLong(); 

23 _collector.emitDirect(t, _coordStream, new Values(batchId, count), r); 
24 finish.vals.add(r); 

25 } 

26 _finishConditions.put(batchIdVal, finish); 

27 return tasks; 

28 } 

29 


30 GOverride 


31 public void emitDirect(int task, String ignore, List«Object» values, Object msgId) { 
32 throw new RuntimeException("Trident does not support direct emits from spouts"); 


35 @Override 


36 public void reportError(Throwable t) { 
37 . collector.reportError(t); 


38 
39 ] 


没有 对 消息 进行 跟踪 ， 


O 第 10~29 行 实现 的 emit 方 法 , 是 这 个 类 的 核心 。RichSpoutBatchId 实 现 了 IBatchId 接 口 , 但 
其 attempId 始 终 为 0。 事 务 尝试 也 实现 了 IBatchId 接 口 ， 它 则 主要 用 于 事务 Topology。 

口 第 10~11 行 用 随机 数 的 方式 产生 了 一 个 事务 尝试 序号 。 

口 第 12~13 行 定义 了 一 个 FinishCondition 变 量 ， 并 将 输入 消息 的 MessageId 赋 值 给 它 。 

a 第 15 行 将 消息 发 送出 去 ,消息 的 第 1 列 为 通过 随机 方法 产生 的 事务 序号 。 可 以 看 到 此 处 并 


由 被 代理 的 Spout 发 送出 来 的 消息 的 Messageld 只 是 被 存储 于 Finish 


Condition 变 量 中 。 


a 第 15 行 返回 的 TaskId 为 outputTasks 的 子 集 。 
a 第 17~25 行 通过 emitDirect 的 方式 向 其 协调 流 发 送 一 条 消息 ， 格 式 为 < 事务 序号 , 消息 条 数 


( 0 或 1 ) >， 同 时 产生 一 个 随机 数 用 来 跟踪 消息 。 
目前 的 代码 中 有 一 个 Bug， 需 要 在 第 25 行 之 后 添加 下 面 的 代码 来 构建 正确 的 映射 关系 : 


_msgIdToBatchId.put(r, batchIdVal); 


第 26 行 将 存储 batchId 和 FinishCcondition 间 的 关系 。 最 后 来 看 流 的 声明 方法 ， 相 关 代码 如 下 : 


public void declareOutputFields(OutputFieldsDeclarer declarer) { 
Fields outFields - TridentUtils.getSingleOutputStreamFields( delegate); 
outFields - TridentUtils.fieldsConcat(new Fields("$id$"), outFields); 
declarer.declareStream( stream, outFields); 
// try to find a way to merge this code with what's already done in TridentBoltExecutor 
declarer.declareStream( coordStream, true, new Fields("id", "count")); 


} 


RichSpoutBatchTriggererli'declareOutputFields KZH Sint. 


Q stream: 其 列 为 “$id$” 加 上 原 有 的 列 。 
口 _coordStream: 其 列 为 “$id$” 和 消息 数目 。 
由 于 只 对 发 送 到 协调 流 的 消息 进行 了 跟踪 , 因此 当 收 到 所 有 发 送 到 协调 流 的 消息 后 , 将 调 
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用 代理 类 的 ack 方 法 ， 该 方法 的 代码 如 下 : 


public void ack(Object msgId) ( 
Long batchId = _msgIdToBatchId.remove((Long) msgId); 
FinishCondition cond = _finishConditions.get(batchId) ; 
if(cond!-null) { 
cond.vals.remove((Long) msgId); 
if(cond.vals.isEmpty()) { 
_finishConditions.remove(batchId) ; 
_delegate.ack(cond.msgId) ; 


} 
fail 方 法 的 实现 与 ack 方 法 类 似 ， 只 不 过 其 在 收 到 任何 一 条 失败 消息 时 均 会 直接 调用 
_delegate 的 fail 方 法 。fail 方 法 的 代码 如 下 : 
public void fail(Object msgId) { 
Long batchId = _msgIdToBatchId.remove((Long) msgId); 
FinishCondition cond = finishConditions.remove(batchId); 


if(cond!-null) { 
. delegate.fail(cond.msgId); 
} 


} 


这 里 需要 根据 msgId 找 到 batchId。msgId 为 发 送 协调 消息 时 产生 的 随机 数 。 
其 他 的 方法 都 较为 直观 ， 这 里 不 再 一 一 讨论 。 


25.5 completeDRPC 操作 


在 Trident 中 ， 需 要 添加 DRPC Spout 节 点 ， 而 当 DRPC 请 求 被 处 理 后 ， 又 需要 有 节点 可 以 将 结 
果 发 送 回 DRPC 服务 器 。 类 TridentTopology 的 completeDRPC 操 作 即 可 用 来 完成 对 这 部 分 节点 的 构 
建 ， 该 类 的 定义 如 下 : 


1 private static void completeDRPC(DefaultDirectedGraph«Node, IndexedEdge» graph, Map«String, 
List«Node»» colocate, UniqueIdGen gen) { 
2 List«Set«Node»» connectedComponents - new ConnectivityInspector«Node, 
IndexedEdge» (graph) . connectedSets() ; 


3 

4 for(Set«Node» g: connectedComponents) { 

5 checkValidJoins(g); 

6 } 

7 

8 TridentTopology helper = new TridentTopology(graph, colocate, gen); 
9 for(Set«Node» g: connectedComponents) { 

10 SpoutNode drpcNode - getDRPCSpoutNode(g); 

11 if(drpcNode!-null) { 

12 Stream lastStream - new Stream(helper, null, getLastAddedNode(g)); 
13 Stream s - new Stream(helper, null, drpcNode); 

14 helper.multiReduce( 


15 s.project(new Fields("return-info")) 
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O 第 2 行 根据 有 向 图 的 最 大 连通 子 图 算法 获得 最 大 连通 子 图 集合 。 第 6~7 行 对 每 一 个 连通 
通 集合 中 ， 不 能 同时 含有 基本 类 


合 进行 检查 : 任何 一 个 连 ; 


.batchGlobal(), 
lastStream.batchGlobal(), 
new ReturnResultsReducer(), 
new Fields()); 


当然 ， 


— 点 ， 


MENE E 
pedes 节点 。 


3E 


个 连通 子 图 中 是 可 以 含有 多 个 基本 类 型 Spout 节 点 的 。 
a 第 9~21 行 对 含有 DRPC Spout 节 点 连通 子 图 进行 处 理 ， 此 处 需要 对 两 个 流 进 行 连接 操作 。 
口 第 13 行 以 DRPC Spout 节 点 为 输入 创建 一 个 新 的 流 s; 第 


型 和 DRPC 类 型 两 类 Spout 节 点 。 


15 行 调用 该 流 的 映射 操作 ， 创 建 一 


该 节点 的 输出 中 将 含有 一 列 return-info 信 息 。 


点 实际 上 是 根据 事务 序号 执行 的 连接 操作 。 
completeDRPC 操 作 构 建 的 节点 如 图 25-2 所 示 。 


导 该 连通 子 图 中 最 后 添加 的 节点 ， 即 creationIndex 
在 DRPC 对 应 的 连通 子 图 中 ， 该 节点 是 查询 消息 结果 所 对 应 的 节点 。 

口 同时 ， 调 用 这 两 个 流 的 batchGlobal 操 作 来 创建 分 区 节点 ， 使 得 具有 相同 事务 尝试 序号 的 
节点 可 以 到 达 相 同 的 目标 节点 。 
a 第 4~19 行 利用 multiReduce 操 作对 这 两 个 流 进 行 连接 处 理 。 
类 ReturnResultsReducer 用 于 处 理 并 返回 结果 到 DRPC Server. 
于 这 两 个 流 的 源头 为 同一 个 DRPC Spout 节 点 ， 具 有 相同 的 事务 序号 ， 因 此 multiReduce 节 
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分 
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25.6 ”返回 DRPC 结果 


ReturnResultsReducer 类 用 来 将 DRPC 的 结果 返回 给 DRPC 服 务 器 。 

ReturnResultsState 类 用 来 存储 DPRC 的 结果 ， 是 ReturnResultsReducer 类 操作 的 数据 。 
ReturnResultsReducer 操 作 所 在 的 Bolt 节 点 将 接收 两 个 流 ，returnInfo 从 其 中 一 个 流 获得 , 包含 了 
这 次 DRPC 请 求 的 来 源 DRPC 服 务 器 信息 , 请 求 结果 需 要 发 送 给 该 DRPC 服 务 器 。 而 results 为 消息 
列表 ， 从 另外 两 个 流 获得 ,代表 了 查询 的 结果 。 该 类 的 定义 如 下 : 


public static class ReturnResultsState { 
List«TridentTuple» results = new ArrayList<TridentTuple>(); 
String returnInfo; 


@Override 


public String toString() { 
return ToStringBuilder.reflectionToString(this) ; 
} 


} 
下 面 我 们 再 来 看 ReturnResultsReducer 类 的 实现 : 


1 public class ReturnResultsReducer implements MultiReducer<ReturnResultsState> { 
2 boolean local; 

3 

4 Map«List, DRPCInvocationsClient» clients = new HashMap«List, DRPCInvocationsClient>(); 
5 

6 

7 @Override 

8 public void prepare(Map conf, TridentMultiReducerContext context) { 

9 local = conf.get(Config.STORM CLUSTER MODE) .equals("local"); 

10 } 

11 


42 @Override 

13 public ReturnResultsState init(TridentCollector collector) { 
14 return new ReturnResultsState(); 

15 1 


17 @Override 
18 public void execute(ReturnResultsState state, int streamIndex, TridentTuple input, 
TridentCollector collector) { 


19 if(streamIndex==0) { 

20 state.returnInfo = input.getString(0); 
21 } else { 

22 state.results.add(input) ; 

23 } 

24 ] 

25 


26 @Override 

27 public void complete(ReturnResultsState state, TridentCollector collector) { 
28 // only one of the multireducers will receive the tuples 

29 if(state.returnInfo!=null) { 
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30 String result - JSONValue.toJSONString(state.results); 
31 Map retMap - (Map) JSONValue.parse(state.returnInfo); 
32 final String host - (String) retMap.get("host"); 

33 final int port = Utils.getInt(retMap.get("port")); 

34 String id - (String) retMap.get("id"); 

35 DistributedRPCInvocations.Iface client; 

36 if(local) ( 

37 client = (DistributedRPCInvocations.Iface) ServiceRegistry.getService(host); 
38 } else { 

39 List server = new ArrayList() {{ 

40 add(host); 

41 add(port); 

42 H; 

43 

44 if(!_clients.containsKey(server)) { 

45 _clients.put(server, new DRPCInvocationsClient(host, port)); 
46 } 

47 client = _clients.get(server) ; 

48 } 

49 

50 try { 

51 client.result(id, result); 

52 } catch(TException e) { 

53 collector.reportError(e); 

54 } 

55 } 

56 } 

57 


58 GOverride 
59 public void cleanup() ( 


60 for(DRPCInvocationsClient c: clients.values()) { 
61 c.close(); 

62 } 

63 } 

64 } 


O 第 4 行 定义 的 _clients 成 员 变 量 用 来 缓存 客户 端 到 DRPC 服 务 器 。 

a 第 13~15 行 的 init 方 法 用 于 初始 化 ReturnResultsState 对 象 。 

口 第 18~24 行 的 execute 方 法 会 根据 输入 消息 的 流 序号 来 判断 信息 属于 哪 种 类 型 ， 或 者 为 
return-info 或 者 为 处 理 结 

O 第 27~56 行 的 complete 方 法 用 于 表明 一 个 请 求 已 经 处 理 结束 。 若 包含 处 理 结果 ， 则 从 
return-info 中 获取 DRPC 服 务 器 的 主机 名 和 端口 号 。 

a 第 37 行 获得 DRPC 服 务 器 的 客户 端 client， 第 51 行 调用 result 方 法 将 结果 返回 。 第 59~63 
行 中 的 close 方 法 则 会 将 DRPC 客 户 端 关 闭 。 
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操作 流 、 执 行 Topology 以 及 运转 DRPC 的 过 程 使 Trident 获 得 了 基本 的 Spout 和 Bolt 节 点 。 类 
TridentTopologyBuilder 将 构建 Storm 所 运行 的 Topology， 并 负责 生命 系统 流 以 及 Topology 与 该 流 
的 收听 关系 ， 这 部 分 是 较为 复杂 的 。 


26.1 基本 工具 函数 


本 节 对 构建 Topology 的 过 程 中 需要 用 到 的 一 些 重要 抑 数 进行 介绍 ， 它 们 是 理解 的 难点 。 


N 


26.1.1 committerBatches 


当 一 个 处 理 节 点 中 含有 State 对 象 时 ， 其 committer 变 量 将 被 设置 为 真 。 若 一 个 节点 组 中 含有 


一 oO 


一 个 具有 存储 对 象 的 节点 ， 则 该 节点 组 将 被 返回 。committerBatches 函 数 用 于 返回 所 有 满足 条 件 
的 节点 组 ， 其 代码 如 下 : 


private static Set«String» committerBatches(Group g, Map«Node, String» batchGroupMap) { 
Set<String> ret = new HashSet(); 
for(Node n: g.nodes) { 
if(n instanceof ProcessorNode) { 
if(((ProcessorNode) n).committer) { 
ret.add(batchGroupMap.get(n)); 
} 
} 


return ret; 


} 


26.1.2 fleshOutStreamBatchIds 


该 函数 返回 从 全 局 流 序号 ( GlobalStreamId ) 到 节点 组 的 映射 关系 ， 它 主要 用 于 构建 系统 的 
全 局 流 序号 与 节点 组 的 映射 关系 。 

变量 _batchIds 中 含有 用 户 定义 的 从 Topology 全 局 流 序号 到 节点 组 的 映射 关系 ，fleshOutput 
StreamBatchIds 函 数 将 这 一 映射 关系 经 过 计算 然后 添加 进 _patchlds 中 去 。 具 体 涉及 的 流 为 : 
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口 MasterBatchCoordinator 节 点 的 $commit 和 $batch 流 ; 
口 _spouts 中 的 $batch 流 ; 
口 _bolt 中 的 $coord-bgx 流 ，bgx 代 表 节 点 组 所 对 应 的 序号 。 
其 中 ，jincludeCommitSstream 变 量 表示 是 否 包 含 MasterBatchCoordinator 的 $commit 流 。 注 意 并 不 
是 每 一 个 节点 组 都 存在 MasterBatchCoordinator 节 点 。fleshOutStreamBatchIds 函 数 的 代码 如 下 : 


Map«GlobalStreamId, String» fleshOutStreamBatchIds(boolean includeCommitStream) { 
Map«GlobalStreamId, String» ret = new HashMap«GlobalStreamId, String»( batchIds); 
Set<String> allBatches = new HashSet( batchIds.values()); 
for(String b: allBatches) { 

ret.put(new GlobalStreamId(masterCoordinator(b), MasterBatchCoordinator.BATCH STREAM ID), b); 
if(includeCommitStream) { 
ret.put(new GlobalStreamId(masterCoordinator(b), MasterBatchCoordinator. 
COMMIT STREAM ID), b); 
} 
// DO NOT include the success stream as part of the batch. it should not trigger coordination 
tuples, 
// and is just a metadata tuple to assist in cleanup, should not trigger batch tracking 


} 


for(String id: spouts.keySet()) { 
TransactionalSpoutComponent c = _spouts.get(id); 
if(c.batchGroupId!-null) { 
ret.put(new GlobalStreamId(spoutCoordinator(id), MasterBatchCoordinator.BATCH_ 
STREAM ID), c.batchGroupId); 


} 


//this takes care of setting up coord streams for spouts and bolts 
for(GlobalStreamId s: _batchIds.keySet()) { 
String b = _batchIds.get(s); 
ret.put(new GlobalStreamId(s.get_componentId(), TridentBoltExecutor.COORD STREAM(b)), b); 


) 


return ret; 


26.1.3 getOutputStreamBatchGroups 
该 方法 返回 一 个 输出 流 所 对 应 的 节点 组 ， 其 代码 如 下 : 


private static Map«String, String» getOutputStreamBatchGroups(Group g, Map«Node, String» batchGroupMap) { 
Map«String, String» ret - new HashMap(); 
Set«PartitionNode» externalGroupOutputs = externalGroupOutputs(g); 
for(PartitionNode n: externalGroupOutputs) { 
ret.put(n.streamId, batchGroupMap.get(n)); 


return ret; 
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26.2 TridentTopologyBuilder 


本 节 将 讨论 TridentTopologyBuildez 的 类 实现 ， 主 要 分 析 其 是 如 何 构建 Spout 和 了 Bolt 节点 的 ， 
并 着 重 讲述 其 中 有 关于 系统 流 设 置 的 内 容 。 下 面 首先 对 该 类 的 数据 进行 分 析 。 


26.2.1 成 员 变 量 
TridentTopologyBuilder 的 数据 成 员 分 析 如 下 : 


public class TridentTopologyBuilder { 
Map«GlobalStreamId, String» _batchIds = new HashMap(); 
Map«String, TransactionalSpoutComponent»  spouts = new HashMap(); 
Map«String, SpoutComponent» _batchPerTupleSpouts = new HashMap(); 
Map«String, Component» bolts - new HashMap(); 


Ww o 


) 


口 _batchIds 中 存储 了 Topology 中 每 一 个 从 全 局 流 序号 到 节点 组 的 映射 关系 。 
口 _spouts 存 储 了 从 SpoutId 到 事务 组 件 的 映射 关系 。 事 务 组件 定 义 如 下 : 


private static class SpoutComponent { 
public Object spout; 
public Integer parallelism; 
public List«Map» componentConfs = new ArrayList<Map>(); 
String batchGroupId; 
String streamName; 
} 
private static class TransactionalSpoutComponent extends SpoutComponent { 
public String commitStateId; 
】 


口 batchGroupId 为 Spout 节 点 所 对 应 的 节点 组 。 

O commitStateId 是 事务 组 件 特有 的 ， 对 应 于 ZooKeeper 中 路 径 ， 用 于 存储 元 数据 。 

Q _batchPerTupleSpouts 用 来 存储 从 SpoutId 到 SpoutComponent 的 映射 关系 。 batchPer 
TupleSpouts 中 存储 的 Spout 每 个 事务 只 发 送 一 条 消息 ( 如 DRPC 类 型 的 Spout 节 点 )。 

口 _bolts 保 存 了 系统 中 所 有 的 Bolt 节 点 ， 其 中 Component 的 定义 如 下 : 


private static class Component ( 
public ITridentBatchBolt bolt; 
public Integer parallelism; 
public List«InputDeclaration» declarations = new ArrayList<InputDeclaration>(); 
public List«Map» componentConfs = new ArrayList<Map>(); 
public Set«String» committerBatches; 


) 


committerBatches 成 员 变 量 用 于 表明 哪些 节点 组 与 该 节点 有 联系 。 该 Bolt 节 点 将 收听 这 些 节 
点 组 所 对 应 的 MasterCoordinator 节 点 的 $commit 流 。 
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26.2.2 设置 Spout 节 点 


本 小 节 讨论 Trident 是 如 何 设置 Spout 节 点 并 构建 系统 流 的 ， 相 关 代 码 如 下 : 


1 TopologyBuilder builder = new TopologyBuilder(); 
2 Map«GlobalStreamId, String» batchIdsForSpouts = fleshOutStreamBatchIds(false); 
3 Map«GlobalStreamId, String» batchIdsForBolts - fleshOutStreamBatchIds(true); 


4 


5 Map«String, List«String»» batchesToCommitIds - new HashMap«String, List«String»»(); 
6 Map«String, List«ITridentSpout»» batchesToSpouts - new HashMap«String, List 


7 


<ITridentSpout>>(); 


8 for(String id: spouts.keySet()) { 


9 


24 


TransactionalSpoutComponent c = _spouts.get(id); 
if(c.spout instanceof IRichSpout) { 


//TODO: wrap this to set the stream name 
builder.setSpout(id, (IRichSpout) c.spout, c.parallelism); 
} else { 
String batchGroup = c.batchGroupId; 
if(!batchesToCommitIds.containsKey(batchGroup)) { 
batchesToCommitIds.put(batchGroup, new ArrayList<String>()); 


batchesToCommitIds.get(batchGroup).add(c.commitStateId); 


if(!batchesToSpouts.containsKey(batchGroup)) { 
batchesToSpouts.put(batchGroup, new ArrayList<ITridentSpout>()); 
} 


batchesToSpouts.get(batchGroup).add((ITridentSpout) c.spout) ; 


BoltDeclarer scd = 
builder.setBolt(spoutCoordinator(id), new TridentSpoutCoordinator 
(c.commitStateId, (ITridentSpout) c.spout)) 
.globalGrouping(masterCoordinator(c.batchGroupId), MasterBatchCoordinator. 
BATCH STREAM ID) 
-globalGrouping(masterCoordinator(c.batchGroupId), MasterBatchCoordinator. 
SUCCESS STREAM ID); 


for(Map m: c.componentConfs) { 
scd.addConfigurations (m); 
} 


Map«String, TridentBoltExecutor.CoordSpec» specs = new HashMap(); 
specs.put(c.batchGroupId, new CoordSpec()); 
BoltDeclarer bd = builder.setBolt(id, 
new TridentBoltExecutor( 
new TridentSpoutExecutor ( 
c.commitStateId, 
c.streamName, 
((ITridentSpout) c.spout)), 
batchIdsForSpouts, 
specs), 
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46 c.parallelism); 

47 bd.allGrouping(spoutCoordinator(id), MasterBatchCoordinator.BATCH STREAM ID); 

48 bd.allGrouping(masterCoordinator(batchGroup), MasterBatchCoordinator. 
SUCCESS STREAM ID); 

49 if(c.spout instanceof ICommitterTridentSpout) { 

50 bd.allGrouping(masterCoordinator(batchGroup), MasterBatchCoordinator. 

COMMIT STREAM ID); 

51 } 

52 for(Map m: c.componentConfs) { 

53 scd.addConfigurations(m) ; 

54 } 

55} 

56 } 

57 


58 for(String id: _batchPerTupleSpouts.keySet()) { 

59 SpoutComponent c = _batchPerTupleSpouts.get(id) ; 

60 SpoutDeclarer d = builder.setSpout(id, new RichSpoutBatchTriggerer 
((IRichSpout) c.spout, c.streamName, c.batchGroupId), c.parallelism); 


62 for(Map conf: c.componentConfs) { 
63 d.addConfigurations (conf); 

64 } 

65 } 


67 for(String batch: batchesToCommitIds.keySet()) { 

68 List«String» commitIds - batchesToCommitIds.get(batch); 

69 builder.setSpout(masterCoordinator(batch), new MasterBatchCoordinator(commitIds, 

batchesToSpouts .get(batch))); 

70 } 

O 第 58~65 行 设置 batchpPerTupleSpout 中 的 Spout 节 点 ,这 里 利用 了 RichSpoutBatchTriggerer 

类 对 其 进行 包装 。 

口 第 5 行 的 batchesToCommitIds 变 量 用 来 存储 从 节点 组 序号 到 ITridentSpout 中 commitStateId 

的 映射 关系 。 

a 第 6 行 的 batchesToSpouts 变 量 用 来 存储 从 节点 组 序号 到 Spout 的 映射 关系 ,一 个 BatchGroup 

中 会 含有 多 个 ITridentSpout 节 点 。 

O 第 67~70 行 设置 Trident 中 的 Spout 节 点 ， 利 用 类 MasterBatchCoordinator 对 节点 组 中 所 有 
ITridentSpout 进 行 封 装 。 可 以 看 出 否 市 点 组 中 没有 ITridentSpout 节 点 ， 则 也 就 没有 
MasterBatchCoordinator 节 点 。 MasterBatchCoordinator 节点 会 向 $commit 、$batch 和 
$success 流 发 送 消 息 。 

OQ 第 8~56 行 处 理 每 一 个 _spouts 节 点 。 第 10~13 行 ， 若 节点 为 IRichspout 类 型 ， 则 直接 调用 
setSpout 方 法 进行 设置 。 第 1$~24 行 更 新 batchesToCommitIds 和 batchesToSpouts 变 量 ， 为 
设置 MasterBatchCoordinator 节 点 做 准备 。 

a 第 27~30 行 设置 了 一 个 Bolt 节 点 ,并 利用 TridentSpoutCoordinator 对 Spout 进 行 封装 ,该 Bolt 
节点 会 收听 MasterBatchCoordinator 节 点 所 对 应 的 $batch 和 $success 流 ， 收 听 方 式 为 全 局 
分 组 方式 。 
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O 第 38~46 行 又 设置 了 一 个 Bolt 节 点 ， 并 利用 TridentBoltExecutor 和 TridentSpoutExecutor 
对 Spout 进 行 封 装 。 第 47~5$1 行 表示 该 节点 将 收听 MasterBatchCoordinator 节 点 的 $success; 
流 和 TridentSspoutCoordinator 的 $batch 流 。 知 Spout 实 现 了 ICommitterTiidentSpout 接 口 ， 
则 还 需要 收听 MasterBatchCoordinator 节 点 的 $commit 流 。 
即 用 户 定义 的 ITridentSpout 将 被 部 团 到 3 个 节点 上 运行 ， 如 图 26-1 所 示 。 读 者 可 结合 代码 自 
行 分 析 。 
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图 26-1 ITridentSpout 的 部 署 以 及 流 


26.2.3 ”设置 Bolt 节 点 
本 节 讨 论 Trident 是 如 何 设置 Bolt 节 点 并 构建 系统 流 ， 相 关 代码 如 下 : 


1 for(String id: bolts.keySet()) { 
Component c = bolts.get(id); 


Map«String, CoordSpec» specs - new HashMap(); 


for(GlobalStreamId s: getBoltSubscriptionStreams(id)) { 
String batch = batchIdsForBolts.get(s); 
if(!specs.containsKey(batch)) specs.put(batch, new CoordSpec()); 
CoordSpec spec = specs.get(batch); 
0 CoordType ct; 
11 if( batchPerTupleSpouts.containsKey(s.get componentId())) ( 
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12 ct = CoordType.single(); 

13 ) else ( 

14 ct = CoordType.all(); 

15 } 

16 spec.coords.put(s.get_componentId(), ct); 

17 } 

18 

19 for(String b: c.committerBatches) { 

20 specs.get(b).commitStream = new GlobalStreamId(masterCoordinator(b), 
MasterBatchCoordinator.COMMIT STREAM ID); 

21 } 

22 


23 BoltDeclarer d = builder.setBolt(id, new TridentBoltExecutor(c.bolt, 
batchIdsForBolts, specs), c.parallelism) ; 


24 for(Map conf: c.componentConfs) { 

25 d.addConfigurations (conf); 

26 } 

27 

28 for(InputDeclaration inputDecl: c.declarations) { 
29 inputDecl.declare(d); 

30 } 

31 


32 Map«String, Set<String>> batchToComponents = getBoltBatchToComponentSubscriptions(id); 
33 for(String b: batchToComponents.keySet()) { 

34 for(String comp: batchToComponents.get(b)) { 

35 d.directGrouping(comp, TridentBoltExecutor.COORD STREAM(b)); 

36 ) 

37 } 


39 for(String b: c.committerBatches) { 
40 d.allGrouping(masterCoordinator(b), MasterBatchCoordinator.COMMIT STREAM ID); 
41 } 


a 第 4 行 的 specs 变 量 用 来 存储 每 个 节点 组 所 对 应 的 协调 关系 定义 (CoordSpec )。 协 调 关 系 定 

义 用 来 描述 该 节点 将 从 哪些 节点 获取 协调 消息 。 

O 第 6~17 行 设置 该 Bolt 的 父 节 点 的 协调 关系 ， 如 果 父 节点 属于 _batchPerTupleSpouts， 则 将 
CoordType 设 置 为 single, 表示 即便 该 组 件 存 在 多 个 并 行 度 , 该 Bolt 也 只 能 从 其 中 一 个 父 节 
点 处 接收 一 条 消息 , 例如, DRPC Spout 中 每 条 Spout 所 发 送 的 消息 都 对 应 于 一 个 新 的 请 求 ， 
该 请 求 会 发 送 到 下 游 的 某 一 个 Bolt 节 点 上 。 其 他 类 型 父 组 件 的 CoordType 为 a1l1， 表 示 为 该 
节点 需要 从 父 节点 的 所 有 并 行 度 中 收取 协调 消息 。 

口 第 39~41 行 表示 若 该 节点 中 含有 State 对 象 ， 则 需要 收听 MasterCoordinator 的 $commit 流 ， 

于 是 该 节点 可 以 获得 一 个 合适 的 时 机 去 更 新 State 对 象 。 

a 第 23 行 表示 Bolt 节 点 都 是 通过 TridentBoltExecutor 进 行 封装 的 。 

a 第 28~30 行 添加 用 户 的 流 声明 。 

O 第 32~37 行 该 Bolt 节 点 通过 直接 消息 分 组 的 方式 收听 父 节 点 的 $coord-bgx 流 ，bgx 为 节点 

序号 。 
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26.3 一 个 例子 


最 后 看 一 下 Storm-Starter 中 Trident Word Count Topology 的 定义 ， 以 及 实际 运行 的 Topology。 
Topology 的 定义 如 下 : 


1 TridentTopology topology = new TridentTopology(); 

2 TridentState wordCounts = 

3 topology.newStream("spouti", spout) 

4 .parallelismHint(1) 

5 .each(new Fields("sentence"), new Split(), new Fields("word")) 
6 .groupBy (new Fields("word")) 

7 .persistentAggregate(new MemoryMapState.Factory(), 

8 new Count(), new Fields("count")) 

9 
1 


.parallelismHint(1); 
0 
11 topology.newDRPCStream("words", drpc).name("DRPCWord") 
12 .each(new Fields("args"), new Split(), new Fields("word")) 


13 .parallelismHint(5) 
14 .groupBy (new Fields("word")).name("DRPCGROUPBY") 


15 .stateQuery(wordCounts, new Fields("word"), new MapGet(), new Fields("count")) 
16 .each(new Fields("count"), new FilterNull()) 

17 .aggregate(new Fields("count"), new Sum(), new Fields("sum")) 

18 $ 


19 return topology.build(); 


首先 ， 由 于 该 例子 没有 恰当 的 使 用 流 的 name 操 作 ， 于 是 Component 的 名 字 基 本 上 为 系统 随机 
取得 的 默认 名 字 ， 这 对 于 调试 过 程 来 讲 简 直 是 灾难 。 系 统 实际 运行 的 Topology 如 图 26-2 所 示 。 

O 系统 中 只 有 一 个 Mastercoord-bg0 节 点 ， 这 是 因为 系统 中 只 存在 一 个 节点 组 含有 State 存 储 

节点 。 

口 用 户 定 义 的 协调 Spout 节 点 被 部 署 到 了 Mastercoord-bg0 和 spout0 上 , Mastercoord-bg0 会 调用 
isReady 图 数 以 确定 是 和 否 该 发 送 一 个 事务 消息 。spout0 收 到 该 事务 消息 后 ， 则 调用 
initializeTransaction 国 数 去 初始 化 一 个 事务 。 

口 Trident 将 Bolt 的 Split 操 作 和 分 区 内 部 的 Count 操 作 放 在 了 $b-1 节 点 上 。 

口 spout1 代 表 了 另外 一 个 节点 组 的 Spout 节 点 ， 它 是 DRPC Spout， 该 Spout 从 DRPC 服 务 获 得 

一 个 请 求 ， 并 向 Topology 发 送 消息 。 

口 b-2 节 点 只 含有 与 DRPC 请 求 源 相 关 的 消息 。 例 如 ， 该 请 求 从 哪个 DRPC 服 务 器 收 到 的 。 

O 节点 b-4 执 行 了 全 局 的 聚集 操作 ， 同 时 将 结果 写 入 state 对象 。 而 且 ， 它 还 需要 完成 来 自 另 

外 一 个 节点 组 的 DRPC 查询 操作 ， 并 将 查询 结果 发 送出 去 。 

O 节点 b-5 会 按照 事务 序号 对 查询 结果 和 消息 来 源 进行 连接 ， 由 此 确定 查询 结果 应 该 发 送 到 

哪 一 个 DRPC 服 务 器 ， 然 后 完成 这 个 发 送 操作 。 

图 26-2 中 的 虚线 表示 为 协调 信息 和 事务 信息 ， 实 线 为 具体 的 数据 信息 。 
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图 26-2 Trident Topology 实 例 
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多 语言 A 


Storm 是 支持 多 语言 的 ， 它 采用 标准 输入 输出 来 与 用 其 他 语言 定义 的 Spout 或 Bolt 进 行 通信 。 
读者 可 参考 下 面 链接 中 的 文档 来 了 解 Storm 的 多 语言 文 持 和 通信 协议 。 
O https://github.com/nathanmarz/storm/wiki/Using-non-JVM-languages-with-Storm 
O https://github.com/nathanmarz/storm/wiki/Multilang-protocol 
通过 标准 输入 输出 进行 进程 间 通信 有 时 候 并 不 能 达到 性 能 要 求 , 这 时 需要 用 户 自 己 来 实现 相 
办 议 从 而 获得 更 高 的 效率 。 
本 章 对 其 中 几 个 重要 的 实现 类 进行 简要 介绍 。 


=} 
Z 


27.1 ShellProcess 


ShellProcess 类 用 于 加 载 一 个 由 其 他 语言 定义 的 进程 ， 并 通过 STDIN 和 STDOUT 进 行 通信 。 
进程 的 参数 被 放 在 command 类 成 员 变 量 中 ,该 变量 将 获得 子 进程 的 标准 输入 输出 和 运行 错误 ， 从 
而 完成 与 子 进程 间 的 通信 。ShellProcess 类 的 定义 如 下 : 


1 public class ShellProcess { 

2 private DataOutputStream processIn; 

3 private BufferedReader processOut; 

4 private InputStream processErrorStream; 
5 private Process subprocess; 

6 private String[] command; 

7 
8 
9 


public ShellProcess(String[] command) { 
this.command = command; 


10 } 

11 

12 public Number launch(Map conf, TopologyContext context) throws IOException { 
13 ProcessBuilder builder = new ProcessBuilder(command) ; 

14 builder.directory(new File(context.getCodeDir())); 

15 _subprocess = builder.start(); 

16 

17 processIn = new DataOutputStream( subprocess.getOutputStream()); 

18 processOut = new BufferedReader(new InputStreamReader( subprocess.getInputStream())); 
19 processErrorStream =  subprocess.getErrorStream(); 

20 


21 JSONObject setupInfo = new JSONObject(); 
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J 
> 


22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 


setupInfo. put 
setupInfo. put 
setupInfo. put 


("pidDir", context.getPIDDir()); 
("conf", conf); 
("context", context); 


writeMessage(setupInfo); 


return (Number)readMessage().get("pid"); 


) 


public void destroy() ( 
_subprocess.destroy(); 


} 
} 


口 第 12~28 行 定义 的 lanuch 方 法 用 于 启动 进程 。 TIU E 


setupInfo, Hifi 


有 Worker 数 据 目 录 下 的 PID 目 录 、Topology 的 配置 项 和 上 下 文 信息 等 


容 。 子 进程 可 以 创建 


一 个 以 自身 进程 ID 为 名 字 的 空 文件 , 并 放置 于 PID 目 录 下 ,; ree 


就 可 以 对 其 启动 的 子 进程 进行 管理 了 。 
O 第 27 行 ，ShellProcess 希 望 用 户 返 回 其 进程 ID (实际 上 最 好 还 是 由 ShellProcess 类 来 创建 


PID 文 件 ， 但 目前 仍 需要 用 户 创建 PID 文 件 )。 


ShellProcess 定 义 了 readMessage、writeMessage 和 getErrorString 方 法 来 与 子 进程 进行 通信 。 


pil 


1 
2 
3 
4 
5 
6 
7 
8 
9 
1 


信 结 束 的 标志 为 end 行 。 下 面 以 readMessage 为 例 进行 代码 分 析 : 


public JSONObject readMessage() throws IOException { 


String string = readString(); 


JSONObject msg - 


(3SONObject)JSONValue.parse(string); 


if (msg != null) { 


return msg; 
} else { 


} 


throw new IOException("unable to parse: 


) 


" 


* string); 


private String readString() throws IOException { 
StringBuilder line - new StringBuilder(); 


//synchronized (processOut) ( 
while (true) { 

String subline = processOut.readLine(); 

if(subline--null) ( 
StringBuilder errorMessage - new StringBuilder(); 
errorMessage.append("Pipe to subprocess seems to be broken!"); 
if (line.length() -- 0) ( 

errorMessage.append(" No output read. n"); 


) 


else ( 


errorMessage.append(" Currently read output: 


} 


+ line.toString() + "\n"); 


errorMessage.append("Shell Process Exception:\n"); 
errorMessage.append(getErrorsString() + "\n"); 
throw new RuntimeException(errorMessage.toString()); 


29 } 

30 if(subline.equals("end")) { 
31 break; 

32 } 

33 if(line.length()!-0) { 
34 line.append("\n"); 
35 

36 line.append(subline) ; 
37 } 

38 //} 

39 

40 return line. toString(); 


41 jJ 


符 串 ， 如 果 所 读 到 的 当前 行为 “end 


a 第 11~41 行 定义 了 私有 的 readString 方 法 。 该 方法 会 不 断 调用 子 进 程 的 标准 输出 来 获取 字 
”， 则 认为 消息 已 经 结束 。 


口 第 17 行 
异常 (RuntimeException )。 


27.2 ShellBolt 


She11Bolt 通 过 自 定义 的 协议 与 子 进程 进行 通信 。 为 了 提 
一 个 用 于 向 子 进程 发 送 消 息 ， 一 个 用 于 从 子 进 程 接收 消息 。 


成 员 变量 


ShellBolt 对 象 的 数据 分 析 如 下 : 


27.2.1 


public class ShellBolt implements IBolt { 
public static Logger LOG = 


1 

2 

3 Process _subprocess; 

4 OutputCollector collector; 

5 Map«String, Tuple» inputs - 
6 

7 private String[] command; 

8 private ShellProcess process; 
9 


private 
10 private 
11 private 
12 private 


volatile boolean running - true; 
volatile Throwable exception; 
LinkedBlockingQueue _pendingWrites = 
Random _rand; 


14 private 
15 private 


Thread _readerThread; 
Thread _writerThread; 


17 public ShellBolt(ShellComponent component) { 


a 第 1~9 行 定义 的 readSstring 方 法 将 按照 JSON 的 格式 对 消息 进 


， 若 收回 的 subline 为 空 ， 表 明子 进程 已 经 不 存在 了 ， 此 时 会 准备 错误 消息 并 抛 出 


行 解析 并 返回 ]SONObject 对 象 。 


高 效率 ，Shel1Bolt 定 义 了 两 个 线程 ， 


LoggerFactory.getLogger(ShellBolt.class); 


new ConcurrentHashMap«String, Tuple»(); 


new LinkedBlockingOueue(); 


18 this(component.get execution command(), component.get script()); 


19 j 
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20 

21 public ShellBolt(String... command) { 
22 command - command; 

23. ] 

24 } 


Q 第 3 行 的 _subprocess 是 利用 ShellProcess 加 载 的 子 进程 。 

口 第 5 行为 目前 消息 的 缓存 。 inputs 的 键 为 一 个 随机 值 ， 用 来 唯一 标识 该 消息 , 其 值 为 消息 
本 身 。 为 了 提高 效率 ，Bolt 会 将 接收 到 的 消息 通过 发 送 线程 不 间断 地 发 送 给 子 进程 。 但 由 
于 从 子 进 程 收回 的 Ack 或 Fail 等 操作 是 异步 的 ， 因 此 Bolt 需 要 根据 随机 的 消息 ID 来 获得 原 
台 消 息 ， 并 对 原始 消息 进行 Ack 或 Fail 操 作 。 

O 第 11 行 的 _ pendingNrites 用 来 对 那些 要 向 子 进程 发 送 的 消息 进行 缓存 , Bolt 的 execute 方 法 

会 将 接收 到 的 消息 放置 于 该 对 列 中 ， 发 送 线程 则 读 取 该 队列 并 将 消息 发 送 到 子 进程 中 。 

O 第 14~15 行 定义 了 读 写 线程 。 


27.2.2 ” 读 写 线程 
本 节 简 要 分 析 一 下 ShellBolt 中 的 读 写 线程 ， 相 关 代码 如 下 : 


1 public void prepare(Map stormConf, TopologyContext context, 

2 final OutputCollector collector) { 

3 _rand = new Random(); 

4 process = new ShellProcess( command); 

5 . collector = collector; 

6 

7 try ( 

8 //subprocesses must send their pid first thing 

9 Number subpid = _process.launch(stormConf, context); 

10 LOG.info("Launched subprocess with pid " + subpid); 

11 } catch (IOException e) { 

12 throw new RuntimeException("Error when launching multilang subprocess\n" + process. 
getErrorsString(), e); 

13 ] 

14 

15 // reader 

16  readerThread = new Thread(new Runnable() ( 

17 public void run() ( 

18 while ( running) ( 

19 try ( 

20 JSONObject action = process.readMessage(); 

21 if (action -- null) ( 

22 // ignore sync 

23 } 

24 

25 String command = (String) action.get("command") ; 

26 if(command.equals("ack")) { 

27 handleAck(action) ; 

28 } else if (command.equals("fail")) { 


29 handleFail(action) ; 
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30 } else if (command.equals("error")) { 
31 handleError(action); 
32 j else if (command.equals("log")) { 
33 String msg - (String) action.get("msg"); 
34 LOG.info("Shell msg: " + msg); 
35 } else if (command.equals("emit")) ( 
36 handleEmit(action); 
37 } 
38 } catch (InterruptedException e) { 
39 } catch (Throwable t) { 
40 die(t); 
41 } 
42 } 
43 } 
4 p 
45 
46  readerThread.start(); 
47 
48  writerThread - new Thread(new Runnable() ( 
49 public void run() ( 
50 while ( running) ( 
51 try ( 
52 Object write = pendingWrites.poll(1, SECONDS); 
53 if (write !- null) ( 
54 . process .writeMessage(write); 
55 } 
56 } catch (InterruptedException e) { 
57 } catch (Throwable t) { 
58 die(t); 
59 } 
60 } 
61 } 
6&2 J; 
63 
64 _writerThread.start(); 
65 } 


口 第 2~13 行 调用 ShellProcess 来 启动 子 进程 。 


口 第 48~62 行 定义 写 线程 ， 即 从 _pendingWrites 

writeMessage 方 法 。 

口 方法 execute 首 先 在 第 7 行为 输入 的 消 
_inputs 中 进行 跟踪 。 

O 在 第 10~16 行 根据 输入 消息 构建 JSON 对 象 ， 并 将 其 
负责 将 消息 发 送出 去 。execute 方 法 的 代码 如 下 : 


public void execute(Tuple input) { 
if ( exception !- null) { 
throw new RuntimeException( exception); 


1 
2 
3 
4 ) 


O 第 16~44 行 定义 读 线程 ,根据 从 协议 返回 的 action 中 获得 的 命令 , ShellBolt 将 执行 相关 操作 。 


中 获取 一 条 消息 并 调用 _process 的 


息 生 成 消息 ID ， 然 后 在 第 8 行将 输入 的 消息 放 入 


E 放 入 _pendingWrites 队 列 中 ,发送 线程 
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5 

6 //just need an id 

7 String genId - Long.toString( rand.nextLong()); 

8 _inputs.put(genId, input); 

9 try ( 

10 JSONObject obj = new JSONObject() ; 

11 obj.put("id", genId); 

12 obj.put("comp", input.getSourceComponent()); 
13 obj.put("stream", input.getSourceStreamId()); 
14 obj.put("task", input.getSourceTask()); 

15 obj.put("tuple", input.getValues()); 

16 _pendingWrites.put(obj) ; 

17 } catch(InterruptedException e) { 

18 throw new RuntimeException("Error during multilang processing", e); 
19 } 


20 } 


handleAck 方 法 会 对 输入 的 消息 进行 Ack 操 作 。 它 从 action 中 获取 消息 ID , 继而 从 _inputs 中 得 
到 原始 消息 ， 然 后 就 可 调用 ack 方 法 。 该 方法 的 代码 如 下 : 


private void handleAck(Map action) ( 
String id - (String) action.get("id"); 
Tuple acked = inputs.remove(id); 
if(acked--null) { 
throw new RuntimeException("Acked a non-existent or already acked/failed id: " + id); 
) 


_collector.ack(acked) ; 


} 
其 他 实现 方法 的 原理 都 大 体 类 似 ， 这 里 不 再 缆 述 。 


27.3 ShellSpout 
ShellSpout 的 实现 过 程 与 shellBolt 的 相近 ， 本 节 简 单 讨论 一 下 其 协议 部 分 ， 相 关 代码 如 下 : 


public void nextTuple() { 
if ( next == null) { 
next = new JSONObject(); 
 next.put("command", "next"); 


querySubprocess( next); 


} 


10 public void ack(Object msgId) { 
11 if ( ack == null) { 


1 
2 
3 
4 
5 
6 
7 
8 
9 


12 _ack = new JSONObject(); 

13 _ack.put("command", "ack"); 
14 } 

15 


16 _ack.put("id", msgId); 
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17 querySubprocess( ack); 

18 } 

19 

20 private void querySubprocess(Object query) ( 

21 try { 

22 _process.writeMessage(query) ; 

23 

24 while (true) { 

25 JSONObject action = _process.readMessage(); 

26 String command = (String) action.get("command") ; 

27 if (command.equals("sync")) { 

28 return; 

29 } else if (command.equals("log")) { 

30 String msg = (String) action.get("msg"); 

31 LOG.info("Shell msg: " + msg); 

32 } else if (command.equals("emit")) { 

33 String stream = (String) action.get("stream") ; 

34 if (stream == null) stream = Utils.DEFAULT STREAM ID; 
35 Long task = (Long) action.get("task"); 

36 List<Object> tuple = (List) action.get("tuple"); 

37 Object messageId - (Object) action.get("id"); 

38 if (task == null) { 

39 List<Integer> outtasks = _collector.emit(stream, tuple, messageId); 
40 Object need_task_ids = action.get("need_task_ids"); 
41 if (need task ids == null || ((Boolean) need task ids).booleanValue()) { 
42 _process.writeMessage(outtasks) ; 

43 } 

44 } else { 

45 _collector.emitDirect((int)task.longValue(), stream, tuple, messageld); 
46 } 

47 } 

48 } 

49 } catch (IOException e) { 

50 throw new RuntimeException(e); 

51 ) 

52 } 


a 第 20~52 行 定义 的 querySubprocess 是 ShellSpout 的 核心 。 它 在 第 22 行 向 子 进程 写 人 命令 ， 
然后 不 断 接 收 消息 ， 直 到 收 到 sync 命 令 。 收 到 emit 命 令 时 ，querySubprocess 将 从 action 


中 获得 消 


息 tuple、 目 标 taskId (Direct Emitting ) 和 消息 跟踪 序号 messageId。 可 见 消息 的 


跟踪 序号 是 由 子 进程 产生 的 , 子 进程 需要 维护 从 消息 序号 到 消息 的 对 应 关系 ，ShellSpout 
则 并 不 维护 该 映射 关系 。 


O 第 1~8 行 定义 nextTuple 国 数 ， 它 会 发 送 next 命 令 到 子 进 程 ， 并 调用 querySubProcess 函 数 。 
口 第 10~18 行 定义 ack 函 数 ， 即 将 ack 命 令 和 消息 跟踪 序号 发 送 给 子 进程 进行 处 理 。 


第 28 章 


Storm 中 的 配置 项 


Storm 的 配置 数 存 储 在 Config. java 文 件 的 一 个 哈 希 表 中 ， 这 里 每 个 参数 都 有 对 应 的 变量 名 ， 
量 名 到 defaults.yam1 中 定义 的 配置 项 的 转换 规则 为 将 字母 转 成 小 写 , 并 把 ”” 蔡 换 为 “”。 biam. 


public static String STORM ZOOKEEPER SERVERS - 


若 要 在 Clojure 代 码 中 访问 这 些 变量 


STORM- ZOOKEEPER-SERVERS 


， 则 映射 规则 为 将 “” 幸 换 成 为 “-” 


"storm.zookeeper.servers"; 


。 例 如 : 


表 28-1 为 Storm 中 的 配置 项 参数 ， 它 们 的 默认 值 可 通过 defaults.yaml 来 调整 。 


表 28-1 ”Storm 的 配置 项 

$ IJ SA GA fa a X 

dev.zookeeper.path /tmp/dev-storm- N/A 
zookeeper 
drpc.invocations.port 3773 被 DRPC Topology FH , 用 来 获取 DRPC 查 询 请 求 并 发 送 结 
果 的 端口 

drpc.port 3772 DRPC 服 务 器 上 客户 端 用 于 发 送 请 求 并 获取 结果 的 端 
drpc.queue.size 128 DRPC Thrift 服 务 器 中 请 求 队列 的 大 小 
drpc.request.timeout.secs 600 DRPC 请 求 的 超时 时 间 
drpc.worker.threads 64 DRPC 服 务 器 的 工作 线程 数目 
java.library.path sbin JVM 的 Lib 查 找 路 径 
nimbus.childopts -Xmx1024m Nimbus 的 JVM 配 置 
nimbus.cleanup.inbox.freq.secs 600 Nimbus 收 件 箱 清理 的 时 间 间 隔 
nimbus.file.copy.expiration. secs 600 下 载 上 传 的 超时 时 间 
nimbus. inbox. jar.expiration. secs 3600 Jar 文 件 在 收 件 箱 的 存活 时 间 
nimbus .monitor.freq.secs 10 心跳 检查 和 任务 分 配 的 时 间 间 隔 
nimbus.reassign true 表明 检测 到 任务 失败 后 是 否 重 新 分 配 任务 
nimbus.supervisor.timeout.secs 60 Supervisor 的 心跳 超时 间隔 
nimbus.task.launch.secs 120 第 一 次 启动 Task 时 的 超时 设置 
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CHE) 
$e WA SA GA 值 含 义 
nimbus.task.timeout.secs 30 Task 启 动 的 超时 设置 
nimbus.thrift.port 6627 Nimbus 的 服务 器 端口 号 


nimbus.topology.validator 


storm.cluster.mode 


storm.id 


storm.local.dir 

storm.local.mode.zmq 
storm.zookeeper.connection.timeout 
storm.zookeeper.port 
storm.zookeeper.retry.interval 
storm.zookeeper.retry.intervalceiling 
storm.zookeeper.retry.times 
storm.zookeeper.root 
storm.zookeeper.servers 


storm.zookeeper.session.timeout 


supervisor.childopts 
supervisor.enable 
supervisor.heartbeat.frequency.secs 
supervisor.monitor.frequency.secs 


supervisor.slots.ports 


supervisor.worker.start.timeout.secs 


supervisor.worker.timeout.secs 


task.heartbeat.frequency.secs 


task.refresh.poll.secs 


topology.acker.executors 


backtype.storm.nimbus 
.DefaultTopologyValid 
ator 


distributed 


N/A 


D:/Data/Storm/stormData 
false 

15000 

2181 

1000 

30000 

5 

/storm 
["xx.xx.xx.000" 
20000 
-Xmx256m 

true 

5 

3 

[6700~6703] 


120 


30 


10 


配置 Topology 合 理性 检查 插件 


Storm 的 运行 模式 ， 或 者 为 〈lacal ) 模拟 ,或 


者 为 分 布 式 


模拟 模式 需 利 用 LocalC 
Topology 的 名 字 ， 即 用 户 提供 的 名 字 + 


一 标识 ID 


Storm 


uster 类 来 运行 


个 唯 


] 来 存储 本 地 数据 的 路 径 


表明 是 否 在 LocalCluster 模 式 下 使 用 ZMQ 


ZooKeeper 的 连接 超时 时 
ZooKeeper 服 务 器 的 端口 号 
ZooKeeper 操 作 的 重 试 [hi 
ZooKeeper 的 最 大 


li] 


间隔 (未 


ZooKeeper 操 作 的 重 试 次 数 
Storm 元 数据 的 ZooKeeper 根 目录 


ZooKeeper 的 服务 器 耻 地 址 


使 用 ) 


ZooKeeper 客 户 端的 超时 时 间 

JVM 人 参数 ，Worker 的 内 存 限制 

表明 是 否 使 用 该 Supervisor， 用 于 测试 
Supervisor 的 心跳 时 间 间 隔 
Supervisor 检 查 Worker 心 跳 的 时 间 间 隔 
Supervisor 中 Worker 所 对 应 的 端口 号 ， 每 一 个 
端口 号 对 应 一 个 Worker， 故 Supervisor 最 多 可 
以 启动 端口 号 数目 个 Worker 

Worker 第 一 次 启动 时 的 超时 时 间 间 隔 


Abs 


第 一 次 启动 JVM 时 会 存在 额外 负载 ， 故 长 于 


supervisor.worker.timeout.secs 


Worker 的 超时 


HEERA, £ Sup 


的 设置 


rvisor 在 该 时 


oO 


间 内 未 收 到 Worker 的 心跳 ， 则 重启 Worker 
Task 发 送 心 跳 到 ZooKeeper 的 时 
ZMQ 连 接 更 新 时 间 以 及 Topology 是 否 活跃 的 


查询 时 间 


系统 中 Acker Bolt 的 数目 。 若 为 0，Spout 将 直 


接 对 发 送 的 消息 进行 Ack 


间 间隔 
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(E) 
$? HN Sk GA 值 a X 
topology.acker.tasks N/A N/A 
topology.builtin.metrics.bucket.size.secs 60 内 置 统计 信息 的 统计 时 间 间 隔 
topology.debug false 表明 是 否 对 Topology 中 发 送 的 消息 进行 打印 


topology.disruptor.wait. strategy 


topology.enable.message.timeouts 


topology.error.throttle.interval.secs 


topology.executor.receive.buffer.size 
topology.executor.send.buffer.size 


topology.fall.back.on.java.serialization 


topology.kryo.decorators 


topology.kryo.factory 


topology.kryo.register 


topology.max.error.report.per.interval 


topology.max.spout.pending 


topology.max.task.parallelism 


topology.message.timeout.secs 


com.Imax.disruptor. 
Blocking WaitStrategy 


true 


10 


ü 


backtype.storm.serializat 


ion.DefaultKryoFactory 
N/A 


5 


120 


Disruptor Queue 的 等 待 策略 ， 默 认为 等 待 10 
若 没有 消息 则 返 

表明 是 否 人 允许 消息 超时 。 知 为 假 ， 则 Spout 节 
点 不 会 产生 System Tick 消 息 , Spout 的 Pending 
的 消息 的 超时 方法 也 便 不 会 被 调用 ， 因 此 消 
息 不 会 超时 
Stomm 中 利用 ZooKeeper 来 报告 错误 。Storm 规 定 在 
寺 定 的 时 间 区 间 内 ,只 发 送 不 超过 一 定数 目的 错 
误 ， 该 参数 用 来 设 定 这 个 数目 。 它 与 参数 
topology.max.error.report.per.interval 一 起 使 用 
Executor 接 收 消息 Disruptor Queue 的 大 小 


Executor 发 送 消 add Queue 的 大 小 


表明 Kryo 序 列 化 失败 时 ， 是 否 使 用 Java 默 认 
的 序列 化 方法 

用 于 定制 Kryo 序 列 化 实例 ， 其 中 的 类 需要 实 
现 IKryoDecorator 接 

用 于 产生 Kryo 序 列 化 器 的 工厂 方法 

用 户 注 册 的 序列 化 类 


Storm 中 利用 ZooKeeper 来 报告 错误 。Storm 规 
定 在 特定 的 时 间 区 间 内 , 发 送 不 超过 一 定数 目 
的 错误 ， 该 参数 用 来 设 定时 间 区 间 。 与 参数 
topology.error.throttle.interval.secs 一 起 
使 用 

Spout 中 最 大 可 以 处 于 Pending 状 态 的 消息 数目 
消息 的 Pending 是 指 消息 已 经 发 送出 去 , 但 未 
女 到 Ack 或 者 Fail 
处 于 Pending 的 消息 超出 该 设置 后 , Spout 将 不 
发 送 消息 。 
该 配置 项 是 Task 级 别 的 。 例 如 ， 


一 个 Spout 的 


并 行 度 为 10， 该 参数 为 10， 则 所 有 Spout 最 多 
可 以 有 100 条 处 于 Pending 状 态 的 消息 


组 件 的 最 大 并 行 度 
消息 的 超时 时 间 设 置 。 者 Spout 发 送出 去 的 消息 
未 在 该 时 间 内 被 Ack，Storm 会 将 消息 标记 为 失 
败 ， 某 些 Spout 可 以 进行 重 传 或 者 将 消息 忽略 
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(5) 


$? HH 


a X 


topology.name 


topology.optimize 


topology. receiver.buffer.size 


topology.skip.missing.kryo.registrations 


topology.sleep.spout.wait.strategy.time.ms 


topology.spout.wait.strategy 


topology.state.synchronization.timeout.secs 
topology.stats.sample.rate 

topology.tasks 
topology.tick.tuple.freq.secs 


topology.transfer.buffer.size 


topology.trident.batch.emit.interval.millis 


topology.worker.childopts 
topology.worker.shared.thread.pool.size 


topology.workers 


transactional.zookeeper.port 
transactional.zookeeper.root 
transactional.zookeeper.servers 
ui.childopts 

ui.port 

worker.childopts 
worker.heartbeat.frequency.secs 
zmq. hwm 


zmq.linger.millis 


zmq.threads 


默 认 值 
N/A 
true 
8 
false 


backtype. storm. spout. S 
leepSpoutWaitStrategy 


60 
0.05 


1024 
500 


/transactional 


Topology 的 名 字 ， 在 提交 Topology 时 被 自动 
设置 

N/A 

从 ZMQ 接 收 消息 的 批 的 大 小 ， 当 收 到 该 数 E 
的 消息 后 ,将 分 发 消息 到 Executor 的 接收 队 页 
当 Kryo 需 要 不 能 识别 的 类 或 者 序列 化 器 时 ， 
是 否 加 载 Kryo 注 册 的 序列 化 器 ， 否 则 在 遇 到 
该 情况 时 将 抛 出 异常 
SleepEmptyEmitStrategy 的 睡眠 时 间 。 妆 
nextTuple 未 发 送出 去 消息 时 ， 则 令 线 程 睡眠 
该 时 间 

和 上 面 参数 结合 使 用 ,为 当 Spout 的 nextTuple 
未 发 送 消息 时 的 处 理 策略 

Topology 元 数据 的 同步 时 间 
运行 统计 的 采样 频率 

该 参数 与 组 件 相 关 ， 表 示 组 件 的 并 行 度 
Tick 消 息 的 发 送 时 间 间 隔 

Executor 发 送 消息 队列 的 大 小 

Trident 的 Batch 产 生 时 间 间 隔 。 在 过 多 Batch 
被 发 送 时 用 来 控制 流量 

被 类 WindowedTimeThrottler 使 用 
Worker 启 动 的 子 进 程 的 VM 参数 ( 未 使 用 ) 
Worker 中 线程 池 的 大 小 

与 Topology 相 关 ， 表 明和 希望 使 
Worker 来 执行 Topology 

用 于 存储 事务 的 ZooKeeper 端 口号 

用 于 存储 事务 的 ZooKeeper 数 据 的 根 目录 

用 于 存储 事务 的 ZooKeeper 服 务 器 

Storm UI 的 JVM 配 置 

Storm UI 的 端口 号 

Worker 的 JVM 配 置 

Worker 心 跳 的 时 间 间 隔 

ZMQ 的 发 送 队 列 的 高 水 平 线 ，0 表 示 不 设置 
当 队 列 中 有 未 发 送 的 消息 时 ，ZMQ 的 关闭 等 
待 时 间 


多 少 个 


Juri 


ZMQ 的 线程 数 
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